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 a 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?

See the information on the homepage of these docs.

Who has developed the SATRE specification?

Take a look at our Contributors page.

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.

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.

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

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

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 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. At the moment, the SATRE specification contains a set of capabilities marked as “Mandatory” which we believe are essential for a system to be defined as a TRE, as well as many “Recommended” and “Optional” capabilities. Some of the non-mandatory capabilities will likely not be needed for TREs containing data that does not require all the possible protections, and there may well be tradeoffs to be made in terms of accessibility vs security that depend on the data the TRE holds. A future specification may include the idea of different archetypes of TREs, or data sensitivity tiers, with different requirements for each.

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

No. However, it’s intended that SATRE could form the foundation for future standards and guidance on federation, interoperability, and related work.