Frequently Asked Questions

What is a TRE?

TRE stands for Trusted Research Environment. The simplest definition tends to be any kind of computing environment set up for research with sensitive data that has built-in security controls and user access management features. The definition of TRE relevant to SATRE encompasses the set of information governance and data management processes alongside the computing technology used to support research with sensitive data; the definition of sensitive data being broadly any data for which there may be considerations around disclosure control, for any reason.

We recognise that in the UK several other names such as Secure Data Environment or Data Safe Haven have been used in the literature on computing with sensitive data, and that these systems may go by other names elsewhere. For more information about TREs, visit the UK TRE Community website.

Why do we need a Standard Architecture for TREs?

A variety of approaches have been taken to building computing infrastructure and designing processes and policies for research with sensitive data. There are also a range of standards or frameworks that may apply to TREs such as ISO27001 or 5 Safes. However, they don’t provide prescriptive guidance on how TREs comply or achieve accreditation. In recognition of this, SATRE aims to find the commonalities and compile a resource for TRE Operators, Builders and Developers to refer to and benefit from. See What is SATRE? for more information.

How has the SATRE specification been developed and why?

SATRE has been developed as a community-led specification, bringing together knowledge, experience, and best practice from a wide range of organisations across the UK TRE community, including academia, healthcare, industry, and government. It was created through collaboration with over 60 organisations, public engagement, and ongoing feedback to ensure it reflects real‑world needs and practice.

The specification was developed to address the lack of TRE‑specific guidance and to provide a consistent framework for designing, operating, and evaluating Trusted Research Environments. Its aim is to improve trust, interoperability, and efficiency by defining shared capabilities and enabling organisations to assess and enhance their TREs in a structured way.

Who has developed the SATRE specification?

The SATRE specification has been developed by the UK Trusted Research Environment community, led by a collaboration of organisations including the University of Dundee, University College London, the Alan Turing Institute, and partners across academia, healthcare, industry, and government. It is a community‑driven effort, involving contributions from over 60 organisations, ensuring that the specification reflects shared experience, best practice, and the needs of those building and operating TREs in the UK.

How is SATRE structured?

SATRE is structured as a specification that defines the key capabilities required to design, build, and operate a TRE. It is organised around five core pillars. Four of these pillars are relevant to all TREs (information governance, computing technology, data management, supporting capabilities), and a fifth pillar covers federated TREs. Together, these provide a consistent way to understand how a TRE should function across all aspects of its operation.

The specification is hierarchical: high-level principles and pillars are broken down into capabilities, which are then expressed as individual requirements (statements). These statements are classified (e.g. Mandatory, Recommended, Optional) and used as the basis for evaluation, allowing organisations to assess implementation in a structured and comparable way.

Is SATRE an ISO technical standard?

No. The SATRE specification aims to provide a helpful guide for TRE Operators, Builders and Developers. It can be used to inform the development process of new TREs, or to evaluate existing TREs and inform how they could be improved. Evaluating a TRE with the SATRE specification may help to identify which technical standards (e.g. ISO 27001) are already met and which (if any) are desirable to work towards meeting.

How does SATRE relate to other standards?

SATRE is designed to complement, not replace, existing standards and frameworks. Standards such as ISO/IEC 27001 or the NIST Cybersecurity are a good baseline for information security in organisations, but SATRE is focussed on TREs. For example, SATRE adds requirements on public involvement and engagement if you hold publicly owned data.

The (SATRE Control Alignment) Table shows how SATRE practices map to recognised standards and frameworks, helping organisations link SATRE activity to existing control requirements. This enables organisations to demonstrate alignment, identify gaps, and strengthen the human element of their security posture without duplicating or replacing established frameworks.

Does SATRE provide everything I need to build a TRE?

No. The SATRE specification defines a set of stakeholder roles and feature capabilities for TREs, which were decided according to our architectural principles. It does not dictate which specific technologies could or should be used to build a TRE.

What do TRE Builders/Developers gain by reading the SATRE specification?

By reading through the SATRE specification, developers tasked by their institution with designing and/or building a TRE for sensitive data projects can avoid re-inventing the wheel. The specification does not dictate answers to the specific technology or policy choices that need to be made when developing a TRE, but it does provide a guide for thinking about which choices need to be made and what capabilities the TRE should possess.

How do I evaluate a TRE?

A TRE is evaluated in SATRE through a structured self‑assessment against the SATRE specification. Organisations use the SATRE evaluation template (an Excel workbook derived from the specification) to review each requirement across the five pillars and supporting capabilities, scoring their current implementation and recording evidence, justification, and any improvements identified.

In practice, this involves assembling a cross‑functional team (e.g. technical, governance, and data roles), working systematically through each statement, and assigning a score (0 = not met, 1 = sufficient, 2 = satisfied, N/A = not applicable). A detailed evaluation should include supporting rationale and suggested improvements, enabling organisations to identify gaps, prioritise actions, and track progress over time. Further guidance available in the evaluation guidance page (see: Evaluating TREs against SATRE) and past evaluations by other organisations available on our community website.

Can SATRE be applied incrementally?

Yes—SATRE can be applied incrementally.

It is designed as a self‑assessment framework that helps organisations identify gaps, prioritise improvements, and progress over time. The use of Mandatory, Recommended, and Optional classifications supports a phased approach, where organisations meet baseline expectations first and then enhance their capabilities progressively based on need and context.

How long does it take to implement or evaluate SATRE?

The time required will vary depending on factors such as the size and maturity of the TRE, availability of evidence, and level of detail in the evaluation (e.g. simple scoring vs. full justification and improvement planning).

As a guideline, if you have the relevant information governance and operations team members available it could take around two days.

What do TRE Operators gain by evaluating their TRE with SATRE?

See: Why should I evaluate my institution’s TRE?

What does compliance mean?

Compliance, in the context of SATRE, refers to meeting defined requirements or obligations set by standards, regulations, or organisational policies. This often focuses on whether specific controls or activities—such as delivering training or maintaining records—are in place as expected.

SATRE recognises that compliance alone does not ensure effectiveness. While it is important to demonstrate that requirements are met, SATRE emphasises going beyond compliance to understand whether security awareness and training activities are actually influencing behaviours and contributing to better security outcomes.

How do I build and run a SATRE compliant TRE?

We encourage TRE Operators and Builders to publicly evaluate their TREs against the SATRE specification; see Evaluating TREs against SATRE. TRE Developers can use the specification and published TRE evaluations as a starting point.

Some of the evaluated TREs such as the Alan Turing Institute’s Data Safe Haven and the University of Dundee Health Informatics Centre’s TREEHOOSE are deployed from open source infrastructure-as-code, and can be deployed by other institutions.

Is the SATRE specification set in stone?

Absolutely not. We know that TREs vary greatly in their design architecture, purposes for being built, the kinds of research they support and data they handle. We have tried to build a specification with as broadly useful a set of capabilities as possible, whilst acknowledging these different approaches. We won’t have covered everything, and if you find SATRE valuable, but think there is something we’ve missed, please consider contributing. Additionally, the best practices in TRE provision may evolve over time as technologies and regulations change. We hope that the SATRE specification will be maintained in the future and accommodate these changes as appropriate.

My TRE is designed for data that doesn’t require this level of protection. Should I still follow SATRE?

Yes. Research enabling technologies like TREs work under many different environments and it is helpful to apply common standards or agreed best practices. Even if you do not feel SATRE applies in your context, it is useful to understand the wider community standards as they are there to support and enable research through continuous improvement within the ever changing regulatory landscape. It is good to be prepared in case your data requirements change.

Who is currently using SATRE?

SATRE is being adopted and used by a growing range of organisations across the UK TRE community, including academic institutions, NHS environments, and research organisations.

Examples published on the SATRE community site include the Scottish National and Regional Safe Havens, the East of England SDE, plus links to some commercial evaluations. These organisations have used SATRE to evaluate and improve their TREs and to share their results with the wider community.

SATRE is designed for broad use, so any organisation building or operating a Trusted Research Environment can adopt it and contribute to its continued development.

Does SATRE describe approaches to TRE federation or interoperability of TREs?

Yes.

As of v2.0, SATRE includes a Federation Pillar which provides a framework for establishing and maintaining a SATRE-compliant TRE Federation.

For further information on Federations of TRE see the DARE UK Federation Blueprint, and for a European perspective informed by SATRE see the EOSC-ENTUST Architecture Blueprint & Interoperability Framework.

How can I contribute to SATRE?

You can contribute to SATRE by engaging with the community and helping to improve the specification. This includes providing feedback, sharing your organisation’s evaluations, raising issues or suggestions via the SATRE GitHub repositories, and participating in community discussions and events.

SATRE is community-led, so contributions from TRE Operators, Developers, and Users are actively encouraged to help refine and evolve the framework over time. Our community website has a list of resources for following our project and connecting with us.