SATRE: What it is and why we use it

The following text is a presentation given by Ross Stiven to the Safe Data Access Professional Network on 3 March 2026.

Introduction

Hello everyone and thank you for the opportunity to speak. As advertised, I am going to speak about the DARE UK SATRE specification, and my perspective on it as a product manager working at a commercial TRE provider.

By way of a quick introduction, I am Ross Stiven. I am senior product manager at a company called Aridhia. I won’t rehearse my entire career history, but I actually started out as a data analyst and ended up as a PM almost by accident. I’ve been with Aridhia for just over four years and my two main responsibilities are our metadata catalogue, FAIR Data Services, and our data federation use cases.

As for the company itself, we’re based up in Scotland, but we have users in the UK, EU, US and Australia. Our highest profile client is probably Great Ormond Street who we have a long-standing relationship with.

As I said, today I’m going to talk about why I personally, and we corporately, like SATRE, how we score ourselves and how we use it, and what we see as the gaps in the standard.

Why we like SATRE

There are three main reasons we like SATRE, and I will go through these in turn:

• Openness
• Clarity
• Not just tech

Openness:

The fact SATRE is open is very good, open specifications drive up standards. SATRE has set a baseline for what good TRE provision looks like. Informed users will be able to ask their TRE provider if they use SATRE, and if so, what their score is. As the standard is increasingly adopted (as we hope it will be) it will become more difficult for both public and private TRE providers to have negative answers to both of these questions. Which means they will have to improve their product.

Clarity:

Nationally and internationally, the term Trusted Research Environment is still somewhat ill-defined, the profusion of acronyms alone makes this clear (e.g TRE, SPE, SDE our own DRE). The granular clarity of SATRE provides us all with something we can point to, if you want to know what a TRE is read the SATRE specification. I have actually done this, sharing our annual scoring with prospective users with general questions about what a TRE is.

Not just tech:

Personally, I think this is SATRE’s biggest strength, and was the reason I initially pushed for its adoption within Aridhia. A TRE is not just a secure box for putting sensitive data in. The secure box is indispensable, it’s the foundation stone of the whole enterprise, but a successful TRE requires much more besides and this is clearly explained in the SATRE standard. This is most explicit in the Information Governance and Supporting Capabilities sections, but even the Computing Technology section touches on issues like usability.

So, that’s why we like it. How did we score ourselves and how do we use it?

Scoring

How we do it:

We did it the old fashioned way, staff from different bits of the business gathered in a meeting room and we went through the spec section by section and line by line. We tried to be as dispassionate as possible, and there were genuine debates over some line items.

We did exempt ourselves from items related to data ownership or governance of individual projects, as these are the responsibility of our users. We provide our users with the tools to manage these activities within the TRE, but it’s important that they remain in control of their own data.

For scoring purposes these items were not marked and removed from the overall total, and this was made clear in our published results.

What is the result:

Once scoring is complete we publish the results as a whitepaper on the Aridhia website, the paper is split into two sections. The first section summaries the score for each part of SATRE, with some explanatory notes explaining our scoring. The second section is a full line by line breakdown of our score, I am not sure anyone reads this, but I think it’s important that we continue to provide it transparently.

This is now the third year that we’ve scored the DRE against SATRE, and as long as the standard continues to evolve and has credibility with the TRE community we will continue to do so.

For the record our 2025 score was:

1. Information Governance: 77/80
2. Computing Technology and Information Security: 119/122
3. Data Management: 54/62
4. Supporting Capabilities: 30/30

We are actually scoring for 2026 this afternoon

Why we do this:

There are two primary benefits to scoring annually and publishing the results:

1. Internal yardstick — if SATRE is understood to be, and accepted as, an accurate description a baseline TRE then we have to score our product against it. Honestly assessing our TRE helps us understand both where we have gaps in provision and where the strengths of our product lie. In turn this helps us identify and prioritise development requirements.
2. External communications — to reiterate, clarity is an extremely valuable feature of SATRE, which makes it a useful communication tool. When I am approached with questions about Aridhia in particular or TRE provision in general one of the first resources I share is our SATRE whitepaper. Why? The answer should be obvious at this point — because it provides a solid baseline description of what a TRE must do, and shows how the Aridhia platform measures up against that.

I understand that it would be easy to be cynical about our motivations here, would we be as keen to share our score if it was lower? Perhaps not, but I think that slightly misses the point, because:

1. It would still be valuable to us as an internal yardstick of our progress, helping us improve a platform which after all hosts terabytes of sensitive personal data.
2. Not unrelatedly, as a commercial provider it would be extremely embarrassing for us to have a SATRE score that we felt we couldn’t share. A real ambition for SATRE should be that it is one of the first things prospective users of a TRE ask about it.

Both cases are examples of the openness of the framework helping drive up overall standards of TRE provision. In scenario one the provider can use an existing known good standard for the benefit of themselves, their users and the individuals whose data they hold. In the second scenario, if SATRE is widely understood as important benchmark in the TRE marketplace poor providers are forced to up their game or go out of business, also a net benefit to users and data subjects.

So these are things we like about SATRE, and why we continue to score ourselves against it, but we do think there are gaps.

The gaps in SATRE

It should be clear from our early adoption and continued use of SATRE, that we are supporters of the project. However, that doesn’t make us uncritical friends, we do think there are gaps that need to be addressed in future, in ascending order of importance these are:

1. More detail on metadata catalogue
2. Inclusion of data federation
3. Inclusion of AI tools

The first of these is by some distance the least serious, SATRE does recommend the provision of a metadata catalogue as part of a TRE, but it feels like this could and should be fleshed out. I am the product manager of a metadata catalogue, so I may not be totally unbiased on this point.

The second is data federation, and my understanding is that SATRE will be updated to include federation as feature of a TRE. Whether this should be mandatory or recommended I don’t know , but I think its inclusion is a necessary step for the continued relevance of the specification. We are also involved in the DARE UK TREvolution project, and there is a clear direction of travel within that which suggests federation will be a key part of future TRE provision.

The third is obviously the most challenging, we did actually publish a medium piece on this last year, and conceded that you could argue that some of the existing provisions cover AI e.g.

Your TRE must provide software applications that are relevant to working with the data in the TRE.

But that feels like a very lawyerly argument, and the shift to AI is a profound change in reality that needs to be accounted for on a number of fronts, from user expectations and tool use, running costs, through information governance and platform security.

At the most basic level, should it be permissible for a user in a TRE to interact with an externally hosted AI tool? Our current operating assumption is that there will be a substantial body of TRE users who answer no to that question. Will it be the majority? I don’t know we are only in the foothills of this change. Regardless, it’s too big to ignore, and I am sure SATRE will be updated to reflect that.

So hopefully that gives you all an insight into our thoughts on SATRE as a commercial TRE provider. Why we like it, why we continue to use it and for what purposes, and places where we think it needs to evolve. Thanks very much.