diff --git a/docs/images/Capability_Map/full.drawio.svg b/docs/images/Capability_Map/full.drawio.svg
index dca739f3..fd107c52 100644
--- a/docs/images/Capability_Map/full.drawio.svg
+++ b/docs/images/Capability_Map/full.drawio.svg
@@ -1,4 +1,4 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/docs/source/glossary.md b/docs/source/glossary.md
index 980082b3..c49a96da 100644
--- a/docs/source/glossary.md
+++ b/docs/source/glossary.md
@@ -1,80 +1,50 @@
# Commonly used terms
-(def_actor)=
-
-## Actor
-
-Definition of an actor
-
-(def_application_component)=
-
-## Application component
-
-Definition of a application component
-
-(def_application_service)=
-
-## Application service
-
-Definition of a application service
-
-(def_architectural_principle)=
-
-## Architectural principle
-
-Fundamental guidelines that inform the design, decision making and implementation of a TRE.
-These principles provide a framework to ensure that the design of the underlying components of a TRE are aligned to consistent goals, values and best practices.
-
-(def_business_data_object)=
-
-## Business data object
-
-Definition of decomposition
-
-(def_capability)=
-
-## Capability
-
-An ability that a system possesses.
-Capabilities are typically expressed in general and high-level terms and typically require a combination of organisation, people, processes, and technology to achieve.
-
-(def_capability_decomposition)=
-
-## Capability decomposition
-
-A set of components that realise a capability.
-These components will vary depending on the nature of the capability.
-Business-focused capabilities will be realised by business processes, roles and services.
-Technology-focused capabilities will be realised by applications, application services and interfaces.
-In addition to the components realising the capability, a catalogue of standards, frameworks and controls linked to the capabilities will provide guidance on how to implement the capabilities safely.
-
-(def_component)=
-
-## Component
-
-Definition of a component
-
-(def_process)=
-
-## Process
-
-Definition of a process
-
-(def_role)=
-
-## Role
-
-Definition of a role
-
-(def_specification_pillar)=
-
-## Specification pillar
-
-A specification pillar is a group of related capabilities.
-SATRE has four specification pillars: Information governance, Computing technology, Data management and Supporting Capabilities.
-
-(def_tre_organisation)=
-
-## TRE organisation
-
-A TRE organisation is the set of people, processes and technology that operate and use a particular TRE.
+```{glossary}
+Actor
+ A person, organization, or system that has one or more roles that initiates or interacts with activities.
+ Example: _The SATRE architecture needs actors such as researchers and internal auditors._
+
+Application component
+ An encapsulation of application functionality which is modular and replaceable.
+ Example: _To perform work within a TRE a researcher might need access to a Desktop or command line interface application component._
+
+Architectural principle
+ Fundamental guidelines that inform the design, decision making and implementation of a TRE.
+ These principles provide a framework to ensure that the design of the underlying components of a TRE are aligned to consistent goals, values and best practices.
+
+Business process
+ A set of actions which produce a specific desired outcome.
+ Example: _to access the TRE a researcher needs to complete an onboarding business process._
+
+Capability
+ An ability that a system possesses.
+ Capabilities are typically expressed in general and high-level terms.
+ Achieving a capability typically requires a combination of organisation, people, processes, and technology.
+
+Capability decomposition
+ A set of {term}`components ` that realise a capability.
+ These components will vary depending on the nature of the capability.
+ Business-focused capabilities will be realised by {term}`business processes `, {term}`roles ` and services.
+ Technology-focused capabilities will be realised by {term}`applications `, services and interfaces.
+ In addition to the components realising the capability, a catalogue of standards, frameworks and controls linked to the capabilities will provide guidance on how to implement the capabilities safely.
+
+Component
+ The statements concerning processes, controls, practices and applications that make up a {term}`capability `, together with an importance label.
+
+Data Object
+ A store of data or information.
+ For example: to know what data is stored within the TRE a study database data object is needed.
+ This contains information on the data assets within the TRE, who owns them and other compliance information.
+
+Role
+ A role is a set of connected behaviors, rights, obligations and norms within a TRE system.
+ Roles are occupied by individuals, who are called {term}`actors `.
+
+Specification pillar
+ A specification pillar is a group of related capabilities.
+ SATRE has four specification pillars: Information governance, Computing technology, Data management and Supporting Capabilities.
+
+TRE organisation
+ A TRE organisation is the set of people, processes and technology that operate and use a particular TRE.
+```
diff --git a/docs/source/pillars/computing_technology.md b/docs/source/pillars/computing_technology.md
index 57f8569a..905e1fb3 100644
--- a/docs/source/pillars/computing_technology.md
+++ b/docs/source/pillars/computing_technology.md
@@ -2,8 +2,6 @@
# Computing technology
-This capability concerns what the TRE operator does to manage systems for storing, retrieving, analysing and sending information.
-
```{figure} ../../images/Capability_Map/full.drawio.svg
:alt: SATRE Pillars Capability Map
:align: center
@@ -11,38 +9,42 @@ This capability concerns what the TRE operator does to manage systems for storin
SATRE Pillars Capability Map
```
+This pillar concerns actions taken by the TRE operator to manage TRE computing systems.
+
+Each TRE operator will have its own computing technology requirements.
+The security controls needed by the computing infrastructure will depend on information governance requirements.
+Other computing requirements will be influenced by the technical knowledge and experience of those using the TRE, along with the work they need to perform within the system.
+For example, a data scientist will have very different requirements to a clinician.
+The required compute resources will vary according to the scale of data and computational techniques employed during research.
+
## End user computing
-_The ability of the TRE operator to provide and manage devices, workspaces, interfaces and applications used by researchers to interact with underlying systems and data._
+The ability of the TRE operator to provide and manage devices, workspaces, interfaces and applications used by researchers to interact with underlying systems and data.
-### User interface
+### End user computing interfaces
-_The interfaces used for interacting with the TRE management system and the TRE workspace._
+Software or systems that allows people to interact with the TRE.
+This may include desktop, command-line and/or code-submission interfaces.
```{list-table}
:header-rows: 1
-:name: tab-end-user-user-interface
+:name: tab-end-user-computing-interfaces
* - Statement
- Guidance
- Importance
-* - Your TRE should be accessed via a user interface accessible using commonly available applications.
- - TREs which allow users to connect from their own devices should not require the installation of any bespoke TRE application on the user's device.
- In practice a web browser is the most common way to achieve this.
- - Recommended
+
+* - You must not allow users to copy data out of your TRE via the system clipboard.
+ - A TRE user must not be able to copy sensitive data out of a workspace using the system clipboard.
+ A TRE may allow user to paste text into a workspace.
+ This might not be relevant to your TRE, for example if your user interface does not have a clipboard.
+ - Required
* - Your TRE workspace should provide an environment familiar to your users.
- This may take the form of a virtual Windows or Linux desktops, non-desktop interfaces such as JupyterLab and other web applications, or a terminal.
Bespoke TRE-specific software should be avoided when widely used alternatives already exist.
- Recommended
-* - Your TRE should take accessibility for users with disabilities into account.
- - The restricted nature of TREs means many assistive tools such as screenreaders in a virtual desktop may not be allowed, but other options such as colour schemes, font sizes, and resizing user interface elements, should be supported.
- - Recommended
-* - You should disable the ability to copy data out of your TRE via the system clipboard.
- - A TRE user must not be able to copy sensitive data out of a workspace using the system clipboard.
- A TRE may allow user to paste text into a workspace.
- - Recommended
* - A TRE could restrict data access from researchers entirely and provide an interface for submitting code.
- For example, you might use a system where users submit jobs that run over the data and return results without allowing direct data access.
- Optional
@@ -50,7 +52,7 @@ _The interfaces used for interacting with the TRE management system and the TRE
### Software tools
-_The tools used by researchers inside a TRE, such as programming languages, IDEs and desktop applications._
+The tools used by researchers inside a TRE, such as programming languages, IDEs and desktop applications.
```{list-table}
:header-rows: 1
@@ -59,20 +61,14 @@ _The tools used by researchers inside a TRE, such as programming languages, IDEs
* - Statement
- Guidance
- Importance
-* - Your TRE must provide software applications that are relevant to working with the data in the TRE.
- - The tools provided will depend on the types of data in the TRE, and the expectations of users of the TRE.
- For users working in a TRE via a virtual desktop, this may include programming languages such as Python and R, integrated development environments, Jupyter notebooks, office type applications such as word processors and spreadsheets, command line tools, etc.
- TREs with non-desktop interfaces should similarly consider carefully which applications are best suited for the researchers needs when interacting with the data, for example "point and click" GUI tools for querying a database and generating plots of data.
- The set of tools should be reviewed regularly to ensure they are up to date.
- - Mandatory
+* - Your TRE should be accessed via a user interface accessible using commonly available applications.
+ - TREs which allow users to connect from their own devices should not require the installation of any bespoke TRE application on the user's device.
+ In practice a web browser is the most common way to achieve this.
+ - Recommended
* - Your TRE must provide clear guidance on how to use software tools and work with data in the TRE.
- TREs that provide a virtual desktop environment for researchers to work in should provide documentation detailing the available tools.
TREs where the analysis code is developed on the access machine (as opppose to within the TRE) should provide documentation detailing the mechanism by which code is submitted to the TRE.
- Mandatory
-* - Your TRE should provide tools to encourage best-practice in reproducibly analysing data.
- - Reproducibility of analyses improves auditability and accountability of how data has been used, as well as being best-practice in research.
- This may include version control software, and tools for developing and running data analysis pipelines.
- - Recommended
* - Your TRE should, where possible, automatically apply security related updates for user software.
- Reducing the risk of exploitable vulnerabilities in installed software will increase the security of your TRE.
- Recommended
@@ -80,18 +76,57 @@ _The tools used by researchers inside a TRE, such as programming languages, IDEs
- This may include shared file storage, databases, collaborative writing, and other web applications.
This must only be shared amongst users within the same project.
- Optional
-* - Your TRE could provide limited access to some public software repositories or container registries.
- - For example, a TRE may allow installation of packages from Python or R repositories, or provide an internal mirror with approved packages.
- Similarly a subset of public containers could be made available, or individual container images via an internal container registry.
- - Optional
* - Your TRE could include licenced commercial software if required by researchers, but additional risks must be recorded and mitigated where neccesary.
- For example, if an application must connect to an external licensing server, you must be confident that only licensing information is sent to this server, and that any network connections are secure.
- Optional
+* - Your TRE must provide software applications that are relevant to working with the data in the TRE.
+ - The tools provided will depend on the types of data in the TRE, and the expectations of users of the TRE.
+ For users working in a TRE via a virtual desktop, this may include programming languages such as Python and R, integrated development environments, Jupyter notebooks, office type applications such as word processors and spreadsheets, command line tools, etc.
+ TREs with non-desktop interfaces should similarly consider carefully which applications are best suited for the researchers needs when interacting with the data, for example "point and click" GUI tools for querying a database and generating plots of data.
+ The set of tools should be reviewed regularly to ensure they are up to date.
+ - Mandatory
+```
+
+### Code Version Control System
+
+Systems and tools providing version control and collaboration features for code developed inside the TRE.
+
+```{list-table}
+:header-rows: 1
+:name: tab-end-user-code-vcs
+
+* - Statement
+ - Guidance
+ - Importance
+* - Your TRE should provide tools to encourage best-practice in reproducibly analysing data.
+ - Reproducibility of analyses improves auditability and accountability of how data has been used, as well as being best-practice in research.
+ This may include version control software, and tools for developing and running data analysis pipelines.
+ - Recommended
+```
+
+### Artefact management
+
+A service that manages and organises third-party software artefacts such as packaged code libraries or containers.
+
+```{list-table}
+:header-rows: 1
+:name: tab-end-user-artefact-management
+
+* - Statement
+ - Guidance
+ - Importance
+* - Your TRE could provide access to some public software repositories or container registries.
+ - For example, a TRE may allow direct installation of packages from Python or R repositories, or provide an internal mirror.
+ - Optional
+* - Your TRE could tightly control which packages are available.
+ - For example, a TRE may only allow installation of a pre-defined set of approved packages.
+ You might also choose to scan for malicious packages and/or go through an approval process before allowing code into the technical environment.
+ - Optional
```
### Advanced or cluster computing
-_The ability to run analyses requiring more compute resources, or more specialised hardware, than is present in the user's workspace._
+Advanced, powerful computer resources to solve complex problems and process large amounts of data, possibly using specialised hardware.
```{list-table}
:header-rows: 1
@@ -100,6 +135,12 @@ _The ability to run analyses requiring more compute resources, or more specialis
* - Statement
- Guidance
- Importance
+* - Your TRE must maintain segregation of users and data from different projects when using non-standard compute.
+ - High performance or specialist compute is often shared amongst multiple users.
+ Users and data must remain segregated at all times.
+ For example, when using physical compute resources, all sensitive data could be securely wiped before another user is given access to that same node.
+ In a cloud hosted TRE virtual machines could be destroyed and recreated.
+ - Mandatory
* - Your TRE should be able to provide access to high performance computing or other scaleable compute resource if required by users.
- If a TRE supports users conducting computationally intensive research it should provide access to dynamically scaleable compute or the equivalent.
For example this may be in the form of a batch scheduler on a HPC cluster, or a dynamically created compute nodes on a cloud platform.
@@ -108,13 +149,7 @@ _The ability to run analyses requiring more compute resources, or more specialis
- GPUs and other accelerators are commonly used in machine learning and other computationally intensive research.
TREs should make it clear to users whether GPUs and other resources are available whilst projects are being assessed.
- Recommended
-* - Your TRE must maintain segregation of users and data from different projects when using non-standard compute.
- - High performance or specialist compute is often shared amongst multiple users.
- Users and data must remain segregated at all times.
- For example, when using physical compute resources, all sensitive data could be securely wiped before another user is given access to that same node.
- In a cloud hosted TRE virtual machines could be destroyed and recreated.
- - Mandatory
-* - Your TRE could make data available to researchers using common databases such as PostgreSQL, MSSQL or MongoDB.
+* - Your TRE could make data available to researchers using common database systems such as PostgreSQL, MSSQL or MongoDB.
- Databases must be secured and only accessible to users within the same project.
If shared (multi-tenant) database servers are used, database administrators must ensure that the database server enforces segregation of users and databases belonging to different projects.
- Optional
@@ -122,41 +157,86 @@ _The ability to run analyses requiring more compute resources, or more specialis
- For example, Spark and Hadoop can be used for distributed computing across a cluster.
This may be an advantage where a TRE is using an amount of data that is too large for single-machine computing to be practical.
- Optional
-* - Your TRE could integrate with cloud-native managed services.
- - Cloud providers supply many different managed services.
- Although the cloud provider is responsible for managing the configuration of these services, the TRE operator must ensure that using them does not compromise the security of the TRE.
- - Optional
```
-## Infrastructure analytics
+## Infrastructure management
+
+The ability of the TRE operator to deploy, change or remove physical or virtual infrastructure.
-_The ability of the TRE operator to record and analyse data about the usage of the TRE._
+### Infrastructure deployment
+
+The process of setting up and configuring infrastructure components and resources to support applications or services.
+This involves development, installation, configuration, and validation.
```{list-table}
:header-rows: 1
-:name: tab-end-user-infrastructure-analytics
+:name: tab-infrastructure-deployment
* - Statement
- Guidance
- Importance
-* - Your TRE must record usage data.
- - This may include the number of users, number of projects, the amount of data stored, number of datasets, the number of workspaces, etc.
+* - You must have a documented procedure for deploying infrastructure.
+ - This might, for instance, be a handbook that is followed or a set of automated scripts.
- Mandatory
-* - Your TRE should record which datasets are accessed, when and by who.
- - This helps maintain auditability of how sensitive data has been used.
+* - You should, where possible, automate any repeatable aspects of your deployment.
+ - This might involve using infrastructure-as-code tools or a series of scripts.
- Recommended
-* - Your TRE should record computational resource usage at the user or aggregate level.
- - This is useful for optimising allocation of resources, and managing costs.
+* - You must have a documented procedure for making changes to deployed infrastructure.
+ - This refers both to changes that might be expected in the course of normal operation and emergency changes that might be needed.
+ Your change management process may form part of a wider accreditation such as ISO 27001.
+ - Mandatory
+* - You must test changes before they are used in production.
+ - This might involve a separate development environment or another system for testing.
+ - Mandatory
+* - You should have separate environments for development and testing infrastructure changes before they are committed to production.
+ - If possible, you should automate application of changes between development and production environments.
+ Consider the costs and practicality of whether this will work for your situation.
+ - Recommended
+```
+
+### Infrastructure removal
+
+The process of retiring or removing infrastructure assets that are no longer needed or outdated, ensuring proper data handling and disposal.
+
+```{list-table}
+:header-rows: 1
+:name: tab-infrastructure-removal
+
+* - Statement
+ - Guidance
+ - Importance
+* - You must have a documented procedure for removing infrastructure when it is no longer needed.
+ - Removing unused infrastructure not only reduces costs and management burden but also reduces the attack surface of a TRE and reduces the risk of unaddressed vulnerabilities.
+ - Mandatory
+```
+
+### Availability management
+
+The process of ensuring all IT infrastructure meets the agreed levels of availability.
+
+```{list-table}
+:header-rows: 1
+:name: tab-infrastructure-availability
+
+* - Statement
+ - Guidance
+ - Importance
+* - You should understand the availability and uptime guarantees of any providers that you rely on.
+ - For remote TREs this might include your cloud provider(s) and/or data centre operators.
+ For on-premises TREs, it might be worth using an uninterruptable power supply (UPS) and planning how you would deal with internet outages.
+ - Recommended
+* - You should develop an availability target or statement and share this with your users.
+ - Understanding how and when the TRE might be unavailable will help your projects in planning their work.
- Recommended
```
-## Network management
+### Network management
-_The ability of the TRE operator to administer and secure network infrastructure using applications, tools and processes._
+An application used to manage network infrastructure, ensuring proper functioning, security, and performance.
```{list-table}
:header-rows: 1
-:name: tab-end-user-network-management
+:name: tab-infrastructure-network
* - Statement
- Guidance
@@ -165,60 +245,48 @@ _The ability of the TRE operator to administer and secure network infrastructure
- Network infrastructure must prevent unauthorised access to resources on the network.
This may include firewalls, network segmentation, and restricting connections to the network.
- Mandatory
-* - You must monitor the network configuration of your TRE to check for misconfigurations and vulnerabilities.
- - This may include regular vulnerability scanning, and penetration testing.
- - Mandatory
* - Your TRE must not allow connectivity between users in different projects, or with access to different datasets.
- Connectivity between users in the same project may be allowed, for example to support shared network services within the project.
- Mandatory
* - Your TRE must block outbound connections to the internet by default.
- Limited outbound connectivity may be allowed for some services.
- Mandatory
+* - You must monitor the network configuration of your TRE to check for misconfigurations and vulnerabilities.
+ - This may include regular vulnerability scanning, and penetration testing.
+ - Mandatory
```
-## Infrastructure lifecycle management
+### Infrastructure analytics
-_The ability of the TRE operator to manage necessary physical or virtual infrastructure._
-
-### Deployment management
-
-_The ability of the TRE operator to instantiate, deploy, change or remove deployed infrastructure._
+The ability of the TRE operator to record and analyse data about the usage of the TRE.
```{list-table}
:header-rows: 1
-:name: tab-deployment-management
+:name: tab-end-user-infrastructure-analytics
* - Statement
- Guidance
- Importance
-* - You must have a documented procedure for deploying infrastructure.
- - This might, for instance, be a handbook that is followed or a set of automated scripts.
+* - Your TRE must record usage data.
+ - This may include the number of users, number of projects, the amount of data stored, number of datasets, the number of workspaces, etc.
- Mandatory
-* - You should, where possible, automate any repeatable aspects of your deployment.
- - This might involve using infrastructure-as-code tools or simply a series of scripts.
+* - Your TRE should record which datasets are accessed, when and by who.
+ - This helps maintain auditability of how sensitive data has been used.
+ - Recommended
+* - Your TRE should record computational resource usage at the user or aggregate level.
+ - This is useful for optimising allocation of resources, and managing costs.
- Recommended
-* - You must have a documented procedure for making changes to deployed infrastructure.
- - This refers both to changes that might be expected in the course of normal operation and emergency changes that might be needed.
- Your change management process may form part of a wider accreditation such as ISO 27001.
- - Mandatory
-* - You must test changes before they are used in production.
- - This might involve a separate development environment or another system for testing.
- - Mandatory
-* - You could test changes in a development environment that mirrors your production system.
- - Consider the costs and practicality of whether this will work for your situation.
- - Optional
-* - You must have a documented procedure for removing infrastructure when it is no longer needed
- - Removing unused infrastructure not only reduces costs and management burden but also reduces the attack surface of a TRE and reduces the risk of unaddressed vulnerabilities.
- - Mandatory
```
-### Capacity management
+## Capacity management
-_The ability of the TRE operator to ensure the right amount of resources are available at the right time to provide a service._
+### Capacity planning
+
+The process of forecasting and determining the resources required to meet the demands of an application or system, ensuring that adequate resources are available when needed.
```{list-table}
:header-rows: 1
-:name: tab-capacity-management
+:name: tab-infrastructure-capacity
* - Statement
- Guidance
@@ -229,26 +297,38 @@ _The ability of the TRE operator to ensure the right amount of resources are ava
* - You should ensure that the anticipated needs of projects can be satisfied using available resources.
- Note that this does not require you to accept requests for additional resources, but rather that promises made about resource availability before a project starts should be honoured wherever possible.
- Recommended
-* - You must ensure that the anticipated resource requirements will not result in overspending by the TRE.
- - For cloud-based TREs this may involve budgeting and/or restricting resource consumption on a project-by-project basis.
- For on-premises TREs this may involve managing expectations to match the available resource.
- - Mandatory
-* - You must have a procedure for increasing/decreasing available resources.
+* - You must have a procedure for allocating available resources among projects.
- For cloud-based TREs this may involve scaling resources, such as virtual machines or databases, or deploying additional resources.
For on-premises TREs this may involve a procurement process to ensure that necessary resources are available.
+ Not all requests for capacity increase must necessarily be granted, but having a clear process will help projects understand when/why/how they can make use of additional capacity.
- Mandatory
-* - You must have a procedure to decide when to change capacity.
- - Not all requests for capacity increase must necessarily be granted, but having a clear process will help projects understand when/why/how they can make use of additional capacity.
+```
+
+### Billing
+
+The process of generating and managing invoices and bills for projects within the TRE.
+It involves calculation, issuance, and recording of payments and receipts.
+
+```{list-table}
+:header-rows: 1
+:name: tab-infrastructure-billing
+
+* - Statement
+ - Guidance
+ - Importance
+* - You must ensure that the anticipated resource requirements will not result in overspending by the TRE.
+ - For cloud-based TREs this may involve budgeting and/or restricting resource consumption on a project-by-project basis.
+ For on-premises TREs this may involve managing expectations to match the available resource.
- Mandatory
```
### Configuration management
-_The ability of the TRE operator to identify, maintain, and verify information on IT assets and configurations in the TRE operator._
+The ability of the TRE operator to identify, maintain, and verify information on IT assets and configurations in the TRE operator.
```{list-table}
:header-rows: 1
-:name: tab-configuration-management
+:name: tab-infrastructure-configuration
* - Statement
- Guidance
@@ -275,23 +355,3 @@ _The ability of the TRE operator to identify, maintain, and verify information o
- Virus and malware scans will help identify malicious code which may compromise the security, or correct operation, of the TRE.
- Mandatory
```
-
-## Availability management
-
-_The ability of the TRE operator to ensure all IT infrastructure, processes, tools, roles etc. are appropriate for the agreed availability targets._
-
-```{list-table}
-:header-rows: 1
-:name: tab-availability-management
-
-* - Statement
- - Guidance
- - Importance
-* - You should understand the availability and uptime guarantees of any providers that you rely on.
- - For remote TREs this might include your cloud provider(s) and/or data centre operators.
- For on-premises TREs, it might be worth considering your ISP and electricity provider.
- - Recommended
-* - You should develop an availability target or statement and share this with your users.
- - Understanding how and when the TRE might be unavailable will help your projects in planning their work.
- - Recommended
-```
diff --git a/docs/source/specification.md b/docs/source/specification.md
index 59ee415e..e09209e0 100644
--- a/docs/source/specification.md
+++ b/docs/source/specification.md
@@ -46,18 +46,19 @@ SATRE Specification Architecture
```
{ref}`Architectural Principles `
-: The {ref}`principles ` that all TRE operators looking to use the specification should hold themselves accountable to.
+: The {term}`principles ` that all TRE operators looking to use the specification should hold themselves accountable to.
{ref}`Specification Pillars `
: The broad areas of TRE provisioning the specification covers.
-TRE Capabilities
-: The capabilities within these pillars that TRE operators can measure themselves against.
+Each pillar is broken down into several {term}`TRE Capabilities `.
-TRE Capability Components
-: The statements concerning processes, controls, practices and applications that make up a capability, together with an importance label.
+Each capability consists of one or more {term}`TRE Capability Components `.
-In addition, we also describe some {ref}`roles ` that are necessary for the operation and use of a TRE.
+Together, these provide a framework that TRE operators can measure themselves against.
+
+{ref}`Roles `
+: In addition, we also describe some {term}`roles ` that are necessary for the operation and use of a TRE.
(satre_principles)=
@@ -66,6 +67,7 @@ In addition, we also describe some {ref}`roles ` that are necessary
The SATRE specification has been developed based on the following principles:
- TREs should be as easy as possible for end-users to use (_e.g._ researchers) whilst still remaining secure.
+- TREs should take accessibility for all users, including those with disabilities, into account.
- TRE deployments should be offered that support data of different levels of sensitivity (_e.g._ through a tiered system of technical controls and policies).
- TREs conforming to the specification should be interoperable and provide a familiar end-user experience.
- The specification will be managed and updated following an open, community-driven process, and will not be tied to a single vendor or implementation.