| Item | Statement | Guidance | Importance | Score | Response | Improvements |
|---|
| 1.1.1 | You must gather and monitor the information governance requirements needed to fulfil any legal, regulatory and ethical standards. | Requirements will come from a variety of sources including legislation, contractual obligations and ethical standards.
Requirements must be monitored to ensure the TRE controls remain appropriate. | Mandatory | 2 | The provision of the TRE is contingent on the signing off of legal documents by all parties assuring that local information governance is completed and that all data protection legislation is complete for the data to be used within the project. Only then does the project get a project TRE | |
| 1.1.2 | You must ensure controls are implemented to ensure the requirements are met. | Control implementation should be systematic and directly aligned to the internal and stakeholder requirements. | Mandatory | 2 | No shares can be made outside the project accounts. No role has privileges to make any data available anywhere else through the platform (only through actions against the legal obligation). | |
| 1.1.3 | You must ensure there are adequate resources to meet information governance requirements. | Ensuring information governance controls are suitable and enforced requires an investment of funding and people appropriate to the size of the TRE. | Mandatory | 1 | Legal controls are mirrored by the technology platform implementation. This minimises resources needed for information governance. Audit reports show what is being done by whom. What is accessible to whom and what shares have been made to where. | More legal resources could be dedicated but this is a ubiquitous problem |
| 1.2.1 | You must ensure that changes to policies and standard operating procedures can only be made by trusted individuals. | It is important to ensure that policies and SOPs are relevant, up-to-date and carefully controlled to maintain the integrity and security of your TRE organisation. | Mandatory | 2 | No changes to operating process can be made without the owner of the service and platform approving things. No person has direct control except through system accounts | |
| 1.2.2 | You must use versioning and a codified change procedure for all policies and standard operating procedures. | This includes recording dates of changes, person responsible for carrying out changes, and summary of changes. | Mandatory | 1 | | This is a new area so no changes to policies or operating procedures have arisen yet. |
| 1.2.3 | You should measure the performance of information governance within the TRE with regular reporting available to your TRE organisation’s management team. | This may include reports and dashboards showing security incidents, quality management deviations and audit findings. | Recommended | 2 | Power BI dashboard is visible to see all datasets in all accounts and all shares between accounts within any project. | |
| 1.2.4 | You must audit your TRE organisation against relevant requirements and standards. | If you are publicly accredited against a standard, for instance ISO27001, DSPT, CE+ *etc.*, you must have processes in place to ensure you remain compliant. | Mandatory | 1 | Data platform has option to select ISO27001 or HIPAA levels of regulation. | External registration has not been needed yet, as 'relevant' requirements and standards are not universal. |
| 1.2.5 | You must report on and share outcomes of each audit of your TRE organisation with the required bodies. | This may include regulatory bodies or the organisations that manage accreditations you have. | Mandatory | 1 | | No "required bodies" are involved at present |
| 1.2.6 | You must ensure that suppliers, contractors and sub-contractors with access to your TRE align with your security requirements. | These should be included as mandatory, non-functional requirements in during procurement and contracting.
This will also include contractor staff contracts for example, legal liability and NDAs. | Mandatory | 2 | No suppliers have access. Any sub-contractors are bound by equivalent policies and practices to FTE staff and have less utility on the TRE platform. No supplier would be allowed to access any of the actual TREs deployed for projects. ServiceNow is a workflow engine and this in connection with scripts make any changes or provision objects that comprise a project TRE. | |
| 1.2.7 | You must monitor compliance of your suppliers with the terms of the contracts. | This will include monitoring changes in the services and infrastructure being delivered and quality management within the contractor’s organisation.
This may be done through formal audit or by monitoring change and quality documentation provided by the supplier. | Mandatory | 2 | The platform is the supplier of the project TRE. No suppliers are involved. Snowflake is a PaaS offering and master service agreements and Terms and Conditions embedded in the research collaboration agreement for each TRE apply. | |
| 1.2.8 | You must track and maintain any physical assets used by your TRE. | All physical assets should be maintained and covered by warranty if applicable.
At the end of their lifetime, assets should be securely disposed of in such a way that data cannot be recovered from them. | Mandatory (where physical assets are in scope) | 2 | Not relevant - all cloud based. | |
| 1.2.9 | You must log, track and resolve any issues resulting from deviations from processes, incidents and audit findings. | This process could, for example, be tracked through an electronic record and workflow system with records retained. | Mandatory | 2 | This is standard within our risk and issues management approach for any system / capability | |
| 1.2.10 | You must use reported issues to inform changes, such as for process improvement and risk management. | All issues should be analysed for their root cause and improvements put in place to prevent further occurrence. | Mandatory | 1 | Normal model of operation for all apps in Crick | |
| 1.2.11 | You should collect and maintain quality management data for measuring the effectiveness of a TRE. | Large amounts of data will be produced by elements within the TRE.
These data should be analysed with reports and dashboards provided to guide TRE implementer’s improvements and provide re-assurance to data consumers and data subjects. | Recommended | 1 | Reporting for all project TREs on the TRELLIS TRE Platform enables sight of activity, use and object size and costs | |
| 1.2.12 | You could use a QMS (Quality Management System) to standardise and automate quality management tasks and workflows, and to generate quality data and reports automatically. | A basic QMS could be a set of spreadsheets or documents held in a repository which are manually maintained.
More mature applications will provide workflows and generate quality data through manual and automated actions. | Optional | 2 | Workflow and orchestration are all embedded components in the TRE platform. No human enacts anything except via controlled workflows with audit logs and approvals. | Change to workflows and core platform functionality could be tracked by a QMS if required to meet a standard such as GCP. |
| 1.3.1 | You must have a way to score risk to understand the underlying severity. | You have a risk assessment methodology for scoring risks on multiple axes such as impact and likelihood. | Mandatory | 2 | This is done by the project and their ethical, legal and financial governance flows in to the set up configurations that are then approved. If secure data is needed then ISO27001/HIPAA compliant facilities are provisioned. | It is as yet unclear what extras are need, but it could be that there are gaps that will come through specific situations that occur in operation. |
| 1.3.2 | You must carry out a data processing assessment for all projects requiring a TRE. | A data processing assessment is a process designed to identify risks arising out of the processing of sensitive data and to minimise these risks as far and as early as possible.
This may take the form of an existing regulatory requirements such as Data Protection Impact Assessment. | Mandatory | 1 | The setup process requires description of sensitivity and selection if HIPAA / ISO27001 is required. The overall TRELLIS platform has had a DPIA assessment and RoPA recorded. | It is as yet unclear what extras are need, but it could be that there are gaps that will come through specific situations that occur in operation. |
| 1.3.3 | You must have a process for designing, implementing and recording risk mitigations where indicated by a risk assessment. | Actions that are taken or not taken following a risk assessment must be recorded. | Mandatory | 1 | The projects that own the TRE document risks and mitigations within their ethics, legal and financial documentations | It is as yet unclear what extras are need, but it could be that there are gaps that will come through specific situations that occur in operation. |
| 1.3.4 | You must have a clear set of roles and responsibilities relating to risk including who owns risks and how they are escalated and delegated. | The highest level of risk ownership is the Top Management of the TRE organisation (see Governance Roles).
In order to ensure escalations to this level are rare, suitable structures should be put in place to own, mitigate and accept risk. | Mandatory | 1 | Project Leads hold the risks associated with data governance and these are part of the legal and ethical approval documents. | It is as yet unclear what extras are need, but it could be that there are gaps that will come through specific situations that occur in operation. |
| 1.3.5 | You must understand the risk appetite of your TRE organisation. | This includes understanding ownership of risk, and ability to accept risk which falls outside of the appetite should that become necessary. | Mandatory | 1 | Each project is a TRE and so are covered by the legal and ethical approval documents. The Crick as a platform providing entity is always part of those agreements and offers up the TRELLIS platform as part of the agreements. | It is as yet unclear what extras are need, but it could be that there are gaps that will come through specific situations that occur in operation. |
| 1.4.1 | You must have checks in place to ensure a project has the legal, financial and ethical requirements in place for the duration of the project. | This includes checks that contracts are in place where required, adequate funding is available for the duration of the project, and responsibilities concerning data handling are understood by all parties. | Mandatory | 2 | A project TRE cannot be instantiated on the TRELLIS platform unless all agreements are in place. People centred workflows controls this. | |
| 1.4.2 | You must have checks in place to ensure that any time limited compliance requirements are maintained. | This includes ensuring contracts remain in valid and action is promptly taken should they expire.
Any changes in the status of responsible persons should also be monitored, for example a data owner leaving an organisation. | Mandatory | 2 | All project TREs have a start and end time associated with the legal, ethical and financial approvals. A margin of time is provided for end-of-project completion activities. | |
| 1.4.3 | You must have checks in place to ensure that changes in regulations are met for a project. | 0 | Mandatory | 2 | Inside the Crick strong links to the legal team and the legal agreement embeds the prime structure of the TRELLIS project TRE components. | |
| 1.4.4 | You must have standard processes in place for the end of a project, that follow all legal requirements and data security best practice. | This includes the archiving of quality and log data along with the archiving or deletion of data sets. | Mandatory | 1 | An archiving process is defined and in place. It allows the project to specify the objects and data needing to be archived, and then scripts create copies of these objects into internal storage areas accessible by the project collaborators for their controlled extraction to their own locations. Audit and compliance data and project metadata is not deleted. | Testing will refine the process and identify what needs to be improved |
| 1.4.5 | You could implement a portal that can provide a workflow engine and database which automates the processes within this capability. | A portal should automate as much of the processes within the capability as possible.
Where processes are automated, process maturity is easier to achieve, with more consistent completion and automatic production of quality control and monitoring data. | Optional | 2 | All project TREs are set up in a standard way with standard facilities. | |
| 1.4.6 | You must keep a complete record of all the data assets held within the system. | Details of all data assets (current and past) held by the system should be retained along with meta-data useful for ensuring compliance can be demonstrated.
This would include ownership, data lifecycle, contracts, risk assessments and other quality data.
This is likely to already exist within the wider organisation but may require augmenting for the TRE. | Mandatory | 2 | All project TREs have standard facilities and all these facilities have a standard metadata model and all projects metadata is collected and stored in a common location allows Row Level Security permission access by controlled users holding specific roles. | |
| 1.4.7 | You should keep a complete record of all the research studies and projects within the TRE current and past. | The study register should contain all data related to a study including a reference to data assets, project team members, information asset owners and any compliance activities required. | Recommended | 2 | All project TREs are recorded in the metadata audit and compliance area. | |
| 1.5.1 | You must have a robust method for identifying accredited members of your TRE organisation, prior to their accessing of sensitive data. | This may include ID checks or email/phone verification. | Mandatory | 2 | All project TREs use standard workflows to identify users and assign them roles. Only once approved (record of approval held in the workflow components) do these roles and users get setup. The roles underpin the chain-of-custody process of transferring data form the collaborators home world, into their own TRELLIS account for the project and then into the Collaboration project account and then within the experiment / investigation they are assigned to within the project | |
| 1.5.2 | You must have clear onboarding processes in place for all roles within your TRE organisation. | This may include all members signing role-specific terms of use or confirming that they have completed role specific training. | Mandatory | 2 | As for 1.5.1.
Training for researchers within any Research Performing Organisation suits the needs of that organisation and underpins its legal duties and professional practices. Each participant in a project asserts that their people involved satisfy data protection and best practice standards and training. | |
| 1.5.3 | You must have a set of services to manage access to resources based on identity. | This will include a security model for role based access with technical controls to ensure the principle of least privilege is enforced. | Mandatory | 2 | The separation of roles for the data flow and chain of custody makes this simple. All activities are restricted to the role assigned. Login is controlled by an account for each project. | |
| 1.5.4 | You must not give anyone access to datasets without agreement from the Data Controller. | The Data Controller may choose to delegate this authority. | Mandatory | 2 | The Project TRE implements an agreement between parties where those parties are accountable for the right to use that data within the project inside the TRE. | |
| 1.5.5 | You must have robust and secure applications in place to authenticate users (and services) within the TRE. | The number of authentication applications should be kept to a minimum with common controls and standards applied across all such as MFA, password complexity *etc.*. | Mandatory | 2 | Password secured login and MFA is standard. Each project has a unique login screen. All users hold an email with a recognised Research performing Organisation that is part of the legal agreements. | |
| 1.5.6 | You must give each user of the TRE a unique logon with changes to any records strictly controlled. | The unique identifier and all associated records for a user should be traceable across the entire TRE.
This will include training records, affiliations, contract agreements and ethics approvals where required. | Mandatory | 2 | All set up is configured by system workflows approved within an orchestration engine. | |
| 1.6.1 | You must determine what training is relevant for all roles within the TRE organisation. | This may include, for instance, cyber security training, GDPR training, and higher level training for system operators.
Specialised roles are likely to need more tailored training.
Identification of these specialities should be done through a systematic training needs analysis.
Specific training may also be required based on the data or information asset owner such as GCP. | Mandatory | 2 | The roles within the TRELLIS TRE are aligned to the chain of custody of data from outside the project TRE to inside the Collaboration research project space. It is obvious what training is needed. It is left to the collaborating Research performing Organisations to assign trained people to do these activities and given them the roles for that activity on the chain-of-custody process.
All collaborators are expected within the legal agreements to have trained individuals working on the project. | |
| 1.6.2 | You must ensure that relevant training is available for all roles within the TRE organisation. | All TRE organisation members need to complete all relevant training and keep their training current.
You may need to provide help or guidance to enable them to do so.
Details of what training is needed will have been determined above. | Mandatory | 1 | As 1.6.1 the Research Performing Organisations determine the training needed. It is clear what is needed for the roles within the TRE project environment what capabilities a person needs to have in order to complete it successfully. | It is as yet unclear what extras are need, but it could be that there are gaps that will come through specific situations that occur in operation. |
| 1.6.3 | You must provide repeat or updated training where necessary to account for changes in competency requirements. | Training is not a one-off event.
Electronic reminders for refresher training should be considered.
Ideally, training should remain relevant and so policies and processes should enable people to demonstrate competency rather than unnecessarily repeating training. | Mandatory | 1 | See 1.6.2. All Research Performing Organisations provide a schedule of training that a researcher within their organisation needs to comply with. | It is as yet unclear what extras are need, but it could be that there are gaps that will come through specific situations that occur in operation. |
| 1.6.4 | You must maintain accurate training records that are directly tied to the role and access levels within the TRE. | Training records should be tied to a user record and carefully maintained.
Maintaining training records enables you to ensure all people have completed the required training and that repeat training happens regularly. | Mandatory | 2 | Within the Crick, people who take roles within a Project TRE have training records managed by the Crick. All other Research Performing Organisations would also do this. The legal agreements covering the project discharge this accountability to each project collaborator. | |
| 1.6.5 | You should accept proof of relevant training certifications from trusted third parties. | You might choose to trust certifications provided by known training providers or your institution’s partner organisations. | Recommended | 0 | Not followed, do not see the need as covered by professional conduct and legal agreements | |
| 1.6.6 | You could have a training platform capable of delivering online training in a variety of formats. | This could be a simple content delivery platform or a more comprehensive LMS platform.
It could also include a range of multimedia delivery formats, and accessible training modules for those with access requirements. | Optional | 1 | We do as the Crick for our staff, but the Project TRE platform does not need to have this. | We might choose to do this as usage ramps up - mix of a data science intro to using the Snowflake environment, as well as a refresher on roles/responsibilities when working with it… |
| 1.6.7 | You could implement a learning management system (LMS) to manage courses and deliver training as required. | Where possible an LMS should support a variety of course content and testing. | Optional | 1 | We do as the Crick for our staff, but the Project TRE platform does not need to have this. | See 1.6.6 |
| 1.6.8 | You could ensure that any courses you use are available in standard, transferable formats. | Support for standard formats such as SCORM allows courses to be shared between providers.
This could help facilitate standardisation of training provision for TRE users across organisations. | Optional | 1 | We do as the Crick for our staff, but the Project TRE platform does not need to have this. | See 1.6.6 |
| 1.6.9 | You could keep historical copies of courses in order to demonstrate competency at a given point in time. | Information asset owners and regulators may be required to audit historical records, *e.g.* for clinical trials.
It may be necessary to retain copies of superseded training along with versions of certifications within the training record. | Optional | 1 | We do as the Crick for our staff, but the Project TRE platform does not need to have this. | See 1.6.6 |
| Item | Statement | Guidance | Importance | Score | Response | Improvements |
|---|
| 2.1.1 | 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. | Mandatory | 1 | The data grid visibility is needed when logged into the system (either through the standard snowflake interface or through tools like RStudio). However, forcing this across all possible applications is not realistic. Monitoring when such downloads occur and checking what data is in that download (personal identifying data for example) is something that is in early implementation and has room for extension | Extending the ability to monitor what data has been copied into files and when a file of data is "downloaded" is a key capability to add in to extend the project TRE's security |
| 2.1.2 | 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 | 2 | All users get the same working environment, accessing very similar and familiar computing tooling (databases, compute engines) | |
| 2.1.3 | A TRE could restrict data access from data consumers 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 | 1 | SQL and Python can be written outside and "pasted" in or triggered to run. This code is then sent to the data and processed there with the results being displayed. The same interface allows that and also writing SQL / Python in the standard snowflake interface. Both run the code on where the data is not bringing the data to the users machine. | |
| 2.1.4 | 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 | 2 | A browser is all that is needed to access. SSO integration is possible to allow book mark access. | |
| 2.1.5 | 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 data consumers to work in should provide documentation detailing the available tools.
TREs where the analysis code is developed on the access machine (as oppose to within the TRE) should provide documentation detailing the mechanism by which code is submitted to the TRE. | Mandatory | 1 | The tooling documentation is an area that can always be extended and improved. However Snowflake offers extensive function and process support online in its knowledge libraries | |
| 2.1.6 | 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 | 1 | The users' experience is via a web page and the project TRE eco-system uses SaaS solutions - all of these have security related updates which are provided at source without need for users or the Project TRE platform team to be involved. | |
| 2.1.7 | Your TRE could provide shared services that are accessible to users in the same project. | 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 | 2 | All projects allow all people in the project to share the resources if they are given the roles suited to doing that activity o the chain-of-custody of the data | |
| 2.1.8 | Your TRE must ensure that any shared services are only available to users working on the same project. | Poorly designed shared services could enable the unintended mixing of data between projects.
To prevent this it is necessary that each instance is only shared between users of a single project. | Mandatory | 2 | All project TREs are completely isolated and resourced individually. | |
| 2.1.9 | You must mitigate and record any risks introduced by the use in your TRE of software that requires telemetry to function. | For example, some licenced commercial software must contact an external licensing server at start-up.
You must be confident that only licensing information is sent to this server and that any network connections are secure. | Mandatory | 1 | Only software that runs python or SQL native runs on the data. Other software may be connected and it is this software that we cannot stop form connected only through best practice and through policy adherence. This is the same for all entities unless the embed the software within the platform | We are looking at what software solutions need to be embedded to allow a larger proportion of users access to their known computing tools whilst removing the ability to remove data. This includes ML tooling |
| 2.1.10 | 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 data consumers 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 | 1 | All the basic data wrangling and data management tools are supported. Advanced graphing in native python or R is possible. As is native SQL. Advanced packaged tooling (ML) is not | We are looking at what software solutions need to be embedded to allow a larger proportion of users access to their known computing tools whilst removing the ability to remove data. This includes ML tooling |
| 2.1.11 | 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 | 1 | All scripts can be saved as worksheets so end-end processing is repeatable. All data objects are saveable and achievable so this can be transferred to a FAIR based repository model | |
| 2.1.12 | 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 | 1 | We do not advocate this. Our model would be embedded engines to run such. Python and R libraries are already embedded into the snowflake platform allowing native code running. | |
| 2.1.13 | 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 | 2 | See 2.1.12 and the Python / R package model is controlled at platform level | |
| 2.1.14 | 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 | 2 | This is forced by architecture and all platform facilities (endpoint URLs, roles, login, compute and database storage) | |
| 2.1.15 | Your TRE should be able to provide access to high performance computing or other scalable compute resource if required by users. | If a TRE supports users conducting computationally intensive research it should provide access to dynamically scalable 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. | Recommended | 2 | Infinitely scalable cloud compute is readily available, and only constrained by the budget caps on costs associated by the project (configuration) governance. These caps can be changed. | |
| 2.1.16 | Your TRE should be able to provide access to accelerators such as GPUs if required by users. | 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 | 2 | See 2.1.15 | |
| 2.1.17 | Your TRE could make data available to data consumers 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 | 2 | Standard SQL is a basis of the databases. There is a slight generic syntax difference (as is common across all DBs) | |
| 2.1.18 | Your TRE could integrate with large-scale data analytics tools for working with large datasets. | 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 | 1 | See 2.1.10 | |
| 2.2.1 | 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 | 2 | All infrastructure is deployed using automatic routines on triggers from orchestration workflow scripts. | |
| 2.2.2 | 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 | 2 | See 2.2.1 | |
| 2.2.3 | 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 | 2 | All scripted for deployment are on GitHub with GitHub actions linking to deployment engines | |
| 2.2.4 | You must test changes before they are used in production. | This might involve a separate development environment or another system for testing. | Mandatory | 2 | The full platform TRE eco-system has prod, test and dev instances | |
| 2.2.5 | You should have a development environment that mirrors your production environment which you use to test infrastructure changes before committing them 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 | 2 | see 2.2.4 | |
| 2.2.6 | 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 | 2 | Archive process allows specification and approval documentation for removal of facilities. All metadata is kept to record actions and decisions | |
| 2.2.7 | 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 | 2 | SLAs and contracts underpin all facilities. All facilities are understood within the Service catalogue that is part of the management discipline to maintain and manage all services. | |
| 2.2.8 | 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 | 1 | Basic SLA are provided within the service definition. Indicative service levels are included in the legal terms and conditions relating to the project agreement. | This is an area that will improve as we gain more familiarity of what happens with projects and how they consume the services |
| 2.2.9 | Your TRE must control and manage all of its network infrastructure in order to protect information in systems and applications. | Network infrastructure must prevent unauthorised access to resources on the network.
This may include firewalls, network segmentation, and restricting connections to the network. | Mandatory | 2 | All facilities are provided within cloud environments that are network protected. | |
| 2.2.10 | 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 | 2 | See other comments. All users have unique registrations for each project and these separate the projects and there are no ways a user can move from project TRE A to project TRE B without a relogin and a separation of sessions. | |
| 2.2.11 | Your TRE must block outbound connections to the internet by default. | Limited outbound connectivity may be allowed for some services. | Mandatory | 2 | No outbound connections are possible from within the Project TRE | |
| 2.2.12 | You should be able to monitor the network configuration of your TRE to check for misconfigurations and vulnerabilities. | This may include regular vulnerability scanning, and penetration testing. | Recommended | 2 | The underlying cloud platform implements this | |
| 2.2.13 | You should regularly monitor the network configuration of your TRE to check for misconfigurations and vulnerabilities. | This will involve following the monitoring procedure detailed above. | Recommended | 2 | The underlying cloud platform implements this | |
| 2.2.14 | 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 | 2 | Full metadata monitoring of all objects, users and all code run on all objects by each role. | |
| 2.2.15 | Your TRE should record which datasets are accessed, when and by who. | This helps maintain auditability of how sensitive data has been used. | Recommended | 2 | All accesses to all dataset and all fields can be derived from mining of the calls on the tables. | |
| 2.2.16 | 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 | 2 | All compute usage and storage is captured at the appropriate level and accessible in audit and compliance reporting at project level | |
| 2.3.1 | You must ensure that all projects understand what resources are available and what the associated costs will be before the project starts. | For on-premises systems this might be related to the available hardware, for cloud-based systems there might be limits on how many instances of a particular resource (*e.g.* GPUs) can be used
Projects should use this information to understand whether the available resources will be sufficient for their requirements. | Mandatory | 2 | Configuration for all projects captures this up front (although change is allowed). All parties get a identical configuration for every project TRE. | |
| 2.3.2 | 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 | 2 | All expected needs for any project is scalable - capability based needs (e.g. skill level, competence level, specific software choices) are out of scope. | |
| 2.3.3 | 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 | 2 | All project TREs consume separate and independent resources. No conflicts of priority exist, all are provisioned identically with full access to facilities, only restricted by the financial approval budgets they have. | |
| 2.3.4 | 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 | 2 | Resource Monitors on all computes and storage exist and thresholds on usage over units of time (day / week / month) are set. Trigger levels automatically warn if a threshold limit will be reached soon. | |
| 2.4.1 | You must have a documented procedure for configuring infrastructure. | This might, for instance, be a handbook that is followed or a set of automated scripts. | Mandatory | 2 | All infrastructure configuration is templated and deployment uses config files of parameter values to set up every project in the same way. | |
| 2.4.2 | You should use configuration management tools to automate application of your configuration wherever possible. | This might involve configuration-as-code tools such as Ansible, Chef, Puppet or Windows Desired State Configuration or simply automated scripts. | Recommended | 2 | We use ServiceNow coupled to GitHub and Lambda function images to automate all platform solution components and processes. | |
| 2.4.3 | You should be able to verify whether the configuration is valid. | This might, for instance, involve running your configuration management tool in ‘check’ mode. | Recommended | 2 | This is done through testing. All configurations are proved to work | |
| 2.4.4 | You should regularly verify your TRE configuration. | This will limit the amount of time the TRE can spend in a non-compliant state. | Recommended | 2 | All configuration instructions send back confirmation of success. | |
| 2.4.5 | You must be able to replace a non-compliant TRE with a compliant system. | This might involve reconfiguring a running system or by replacing it with a compliant one. | Mandatory | 2 | There can be no non-compliant project TREs | |
| 2.5.1 | You should keep backups of data and research environments, provided that this is permitted by law. | Keeping backups could help reduce the impact of events like accidental deletion and data corruption on work in a TRE.
TRE developers may want to consider how different elements such as sensitive input data or users’ workspaces may be backed up, and whether they should be. | Recommended | 2 | Not applicable - there is a recovery process inbuilt into thew cloud provider and this is embedded into the terms covered by the legal agreement for the Project TRE. | |
| 2.5.2 | You should build redundancy into infrastructure and storage. | Infrastructure should be as resilient as necessary to interruption.
This could include redundant infrastructure in different physical locations, load balancing and replication of data between multiple storage locations. | Recommended | 1 | As the whole TRE solution (data storage and orchestration and workflow) is held on cloud provided facilities, the redundancy is already factored in. | |
| 2.5.3 | You should keep backups of infrastructure, applications and configurations. | This may include virtualised infrastructure snapshots which can restored as needed to recover from failure. | Recommended | 2 | The Snowflake data facilities have time travel backup capability offering a 90 day potential window for reversing data deletion at a table, schema or database level, the duration is configurable. | |
| 2.5.4 | You must have procedures in place for rapid incident response. | There may be legal requirements to disclose details of any incidents, such as data breaches for organisations subject to GDPR.
Having robust processes in place will ensure a swift and effective response when an incident occurs. | Mandatory | 2 | The Crick has such procedures | |
| 2.5.5 | You should test your incident response through simulation. | During simulated incidents the TRE organisation can measure their effectiveness.
This may involve people across the broader enterprise and/or external suppliers. | Recommended | 0 | The Crick TRELLIS world is relatively new (~1 year as of 2023) and so we have not started this, but would do once the platform has more use. | |
| 2.5.6 | You should have an application in place to scan for vulnerabilities across infrastructure. | Software used to identify vulnerabilities should also report and alert.
Such an alert should be triaged, risk assessed and treated accordingly. | Recommended | 1 | Vulnerability scanning occurs within the cloud infrastructures (Snowflake, AWS, Azure, GCP). In addition, Splunk is used to verify and monitor the pipelines, availability, security etc. of the facilities. | |
| 2.5.7 | You must have a process in place for applying security updates to all software that forms part of the TRE infrastructure. | This includes any software used for remote desktop portals, databases, webapps, creating and destroying compute infrastructure, configuration management, or software used for monitoring the TRE. | Mandatory | 2 | This is done through the cloud providers | |
| 2.5.8 | Infrastructure should be automatically patched for vulnerabilities. | Planning will be required across infrastructure and software systems to ensure security patches remain available from suppliers.
Many systems may be isolated from the internet making TRE infrastructure more difficult to automatically patch. | Recommended | 2 | This is done through the cloud providers | |
| 2.5.9 | You should carry out penetration tests on your TRE. | By intentionally attempting to breach their TRE, organisations can proactively discover unnoticed vulnerabilities before they are exploited maliciously.
Tests can evaluate the effectiveness of security controls in preventing data breaches, unauthorised access, or other security incidents. | Recommended | 1 | This is in the plan but requires scheduling. However all cloud providing parts have already been accredited as having been tested in this way. | |
| 2.5.10 | You should update the security controls of your TRE based on the results of security tests. | Security testing can reveal bugs and discrepancies in the TRE architecture which should be addressed in advance of sensitive data being uploaded, or with urgency in the case of an operational TRE.
Regular testing will allow organisations to refine their TRE security controls and incident response capabilities.
It enables them to adapt to any new security concerns that may arise as a result of changes in the underlying software. | Recommended | 1 | This is an evolving thing and as these come this will be done as there are formal processes within the Crick that ensure that happens for all systems facilities | |
| 2.5.11 | You should publish details of your security testing strategy and, where possible, the results of each test. | Knowledge that regular security testing occurs will help to ensure stakeholders, including data consumers and information asset owners, can trust that the data they work with or are responsible for is secure within a TRE.
If security flaws are identified in a test, it may not be sensible to publicise these until a fix is in place. | Recommended | 1 | This would be done as and when such activity occurs | |
| 2.5.12 | Your TRE must encrypt project and user data at rest. | This prevents unauthorised access to the data even if the storage media is compromised.
This may involve encrypted filesystems or tools to encrypt and decrypt data on demand.
The encryption keys may be managed by the TRE operator or by a trusted external actor, for example a cloud provider. | Mandatory | 2 | This is formally explicit in all components to the TRE platform and is therefore true for all project TREs built on it. | |
| 2.5.13 | Your TRE must encrypt data when in transit between the TRE and external networks or computers. | Data encryption must be used to safeguard against interception or tampering during transmission.
This includes both data ingress and egress and users accessing the TRE, for example over a remote desktop or shell session. | Mandatory | 2 | This occurs as standard within the browser interface. | |
| 2.5.14 | Your TRE should encrypt data when in transit inside the TRE. | If possible, data transfers between different components of a TRE should also be encrypted. | Recommended | 2 | All cloud components satisfy this expectation | |
| 2.5.15 | You should use encryption algorithms and software that are widely accepted as secure. | Encryption algorithms widely accepted as secure today may become insecure in the future, for instance due to newly-identified flaws, or advances in compute capabilities.
The latest security patches and updates should be applied to any encryption software being used by the TRE.
This helps address any known vulnerabilities or weaknesses in the encryption implementation. | Recommended | 2 | This is standard | |
| 2.5.16 | Your TRE should use secure key management. | TREs should employ secure key management practices, including storing encryption keys separately from the encrypted data and implementing strong access controls (*e.g.* Single Sign On) for key management systems. | Recommended | 2 | This is standard | |
| 2.5.17 | Your TRE could offer physical protection measures against data leakage or theft via physical means. | Restricting access to research facilities containing computers logged into TREs can help prevent malicious actors from viewing or stealing sensitive data, for example by photographing a computer screen.
Physical controls on access to a TRE could include surveillance systems, restricting physical access to authorised personnel only, visitor management systems and employee training. | Optional | 2 | There are no machines to allow physical device access except through a download to PC behaviour. Such restrictions are handled through safe people. | |
| 2.5.18 | Your TRE may need to comply with specific regulatory requirements due to the types of data it is hosting. | Regulatory frameworks often emphasise the need for security controls to protect sensitive data.
Compliance with these regulations could require organisations to implement specific security measures to safeguard their TRE from unauthorised access. | Mandatory | 2 | All types of data can be hosted within the 27001 and HIPAA compliant project TRE configurations | |
| Item | Statement | Guidance | Importance | Score | Response | Improvements |
|---|
| 3.1.1 | You must have processes in place to assess the legal and regulatory implications of handling the data through its full lifecycle. | This involves considering your obligations to data controllers and subjects, and whether any security controls may be legally or contractually required.
An assessment of the risks involved will also be needed.
It may involve classifying the project into a predefined sensitivity category or defining bespoke controls. | Mandatory | 2 | This is done through the legal agreements and the full lifecycle from "Initiative 2 Archive". | |
| 3.1.2 | You should keep records of data handling decisions. | Decisions that are made as part of the process discussed above should be recorded and made available for inspection by all stakeholders. | Recommended | 2 | Data can only be handled by people assigned one of the chain-of-custody roles affecting data (there are five and only five roles that a person can be given). All actions are recorded in the metadata. | |
| 3.1.3 | Information asset owners must classify data sets according to a common process and data classification methodology. | To classify the data, information asset owners must have a good understanding of the datasets and the process of classification.
Once classified, data can be stored in a TRE with an appropriate security controls (see later section on security levels and tiering), which can factor in the requirements for confidentiality, integrity and availability of the data. | Mandatory | 1 | The platform offers two levels of data infrastructure: Enterprise and Business Critical. If data needs to be ISO27001 or HIPPA compliant then the TRE project facilities are built at "Business Critical". All projects are self contained and operate with full isolation from others. The project is free to classify its data as it wishes. | |
| 3.1.4 | You must have a data ingress process which enforces information governance rules/processes. | The data ingress process needs to ensure that information governance is correctly followed.
In particular, it should require that an ingress request has been approved by all required parties. | Mandatory | 1 | The project TRE is the facilities that allow the project to complete and do its work. The project is accountable for the legal and ethical compliance. No data should be shared outside that legal agreement for the project. The Project TRE allows each party to have their own private area extending their domain of control. They have the accountability and responsibility to ensure the data ingressed is only that which should be. | |
| 3.1.5 | You must have a data egress process which enforces information governance rules/processes. | The data egress process needs to ensure that information governance requirements are adhered to.
In particular, it should require that an egress request has been approved by all required parties. | Mandatory | 1 | See 12.1.3 but for egress | Output controls are being considered |
| 3.1.6 | Egress must be limited to the information asset owners or their delegates. | Egress of data from a TRE must be a specific permission associated with individual users
This permission must be given by information asset owners.
Egress may still require further approval (see 3.1.5). | Mandatory | 2 | The Project TRE has a collaboration legal agreement that stipulates all collaborating parties are accountable for the data they bring to the collaboration and how the results of work done are owned. Therefore the project participants control what happens to the data and what egress occurs and when . Specifically the archive process once approved drops all objects within a S3 area inside the project which can then be collected by the parties. | |
| 3.1.7 | Your data egress process could sometimes require project-independent approval. | There may be cases where there are multiple stakeholders for a piece of analysis including information asset owners, data analysts, data subjects, the TRE operator.
A data egress process may then require approval from people not on the project team, for example an external referee or TRE operator representative | Optional | 2 | Not applicable - only the project would decide on egress. | |
| 3.1.8 | You must keep a record of what data your TRE holds. | Good records are important for ensuring compliance with legislation, understanding risk and aiding good data hygiene.
The record should include a description of the data, its source, contact details for the data owner, which projects use the data, the date it was received, when it is expected to no longer be needed. | Mandatory | 2 | All fields in all tables are defined in metadata and available in the audit and compliance reporting. | Tagging of data fields is to be considered, to allow obfuscation processes as well as tracking of use through the sql code run records held in the metadata. |
| 3.1.9 | You must have a policy on data deletion. | There should be a clear, published policy on when data will be retained or deleted.
This may allow time for data owners to consider outputs they may want to extract from the TRE.
Any sensitive data, including all backups, should be deleted when they are no longer needed.
Having clear policies will help to avoid problems with data being kept longer than necessary or accidental deletion of outputs. | Mandatory | 2 | The deletion of data is under the control of the project TRE. Archiving process is the only formal process that can delete data by the platform TRE. | |
| 3.1.10 | You should have a method of providing proof of deletion/removal of files. | Information asset owners may require certification of the deletion of files.
You should have a method of providing proof of deletion if challenged. | Recommended | 1 | All activities conducted on the platform are recorded so these can be filtered to any object to show the actions of deletion. | A specific report could be constructed to show these (and any time travel actions that may follow a deletion) |
| 3.1.11 | You should log how input data is modified. | If the input data is mutable a TRE should keep records of its modification.
For example, when the data was modified and by who. | Recommended | 2 | Chain of custody for the data can be derived form the log files of code (how it is used from when it is created and which role completed that work). | |
| 3.1.12 | You must, to a reasonable extent, prevent unauthorised data ingress or egress. | Movement of data which has not been subject to information governance processes risks breaking rules and is more likely to result in a data breach.
However, it is difficult to control for every possibility.
For example, a user may take pictures of their computer screen to remove data, or use a device presenting as a USB HID keyboard to input large amounts of text.
An example of a reasonable measure would be for a remote desktop based TRE to prevent data being copied from a local machine’s clipboard to a workspace. | Mandatory | 2 | There is no ability to obtain unauthorised access to any data throughout the process from loading to the investigator / experimenter. | |
| 3.1.13 | Data held within the TRE should be the minimum required for analysis or research. | Data stored and processed within the TRE should be limited to the amount required for that purpose.
This increases the level of protection for data subjects, makes it easier to comply with data protection legislation and could reduce the overhead of storage and processing. | Recommended | 2 | Each project is a TRE and so are covered by the legal and ethical approval documents. The project decides on the data needed and each participant has the formal accountability to conform to data protection legislation for their data. The projects outputs are the responsibility of the collaboration and are held within the projects specific collaboration account. | |
| 3.2.1 | You must not create user accounts for use by more than one person. | It is important that each user account should be used by one, and only one, person in order to facilitate the assignment of roles or permissions and to log the actions of individuals. | Mandatory | 2 | This is impossible all accounts are specific to users and have MFA options. | |
| 3.2.2 | You must be reasonably convinced of the identity of each person being granted an account. | It is important to ensure an account has been given to the correct person.
For example, multiple credentials may be used before account creation to verify identity or, when appropriate, photo ID checks may be required. | Mandatory | 2 | email verification, plus alignment of the users email suffix to the suffix of the RPO that they are affiliated to, controls this. | |
| 3.2.3 | You must restrict a user’s access to only data required in their work. | There is no need to grant an individual access to data they do not require.
Access may be assigned in a manner appropriate to a TREs design, for example through roles granted to user accounts or through isolated project workspaces. | Mandatory | 2 | All roles in the chain-of-custody between loading and investigator have specific domains of access and which database facilities they can use. Only approved people to specific roles are deployed on the platform TRE for each individual project | |
| 3.2.4 | You must ensure that multi-factor authentication is enabled for all users. | Multi-factor authentication ensures that to successfully connect a user must have more than one piece of evidence in different categories.
Categories include something the user knows (*e.g.* a password), something the user possesses (*e.g.* a TOTP key) or something the user is (*e.g.* biometric data).
A TRE does not need to implement multi-factor authentication checks itself if it is provided by a third-party identity provider. | Mandatory | 2 | MFA is enabled but cannot be forced to be used. | |
| 3.2.5 | You could use federated authentication or single sign-on (SSO) for user login. | Institutions that use a SSO for other applications may wish to extend this login capability to a TRE.
This will simplify the login process for data consumers using a TRE and prevent them having to remember or store multiple login credentials. | Optional | 2 | Internal Crick users for projects can access their project TRE through SSO. | |
| 3.2.6 | You could restrict access to particular networks or physical locations. | Restricting access to a set of known, static, personal or institutional IP addresses can help avoid speculative attacks.
When appropriate, access could also be restricted to physical locations with security controls and access requirements. | Optional | 2 | Not applicable, all projects are closed and defined in a common way. There is no variation in network or physical location except for the one the project TRE facilities have been provisioned. However the project could be provisioned anywhere across the globe where cloud facilities exist. | |
| 3.3.1 | You should have a system to help classify outputs. | Removing data from a TRE can be a difficult process as there is potential for sensitive data to be revealed.
Having guidance, processes and methods will help ensure that outputs are correctly classified and, furthermore, that outputs due to be openly published are identified.
Encouraging openly published outputs will enhance a TRE’s impact and transparency. | Recommended | 1 | Output classification is simplistic at present (data set, analysis result, research paper/policy, method rule) | |
| 3.3.2 | You should establish the intended outputs of each project from the outset. | Identifying the purpose of a piece of work is important for compliance with data protection legislation.
Results will be produced which address the project’s purpose, some of which may be outputs that are removed from the TRE.
Understanding what these outputs are likely to be and their sensitivity as early as possible will help prepare for their processing and publication. | Recommended | 2 | The goals of the project have to be clear as this is what is described in the project ethics, financial approval documents. The legal approval documents may also explain this. It is not possible or sensible to constrain outputs more than this. | |
| 3.3.3 | You must have a documented process for disclosure control of outputs from the TRE. | This process should define expected risks and how to mitigate them.
All TRE outputs must be subject to this process.
You might choose to follow existing guidelines, for example around statistical disclosure. | Mandatory | 1 | It is the expectation that all professional Research Performing Organisations have due diligence on outputs. Because the project TRE is the responsibility and domain controlled by the project TRE only, then it can regulate itself on outputs | |
| 3.3.4 | You must have a process for assigning responsibility for output checking. | Output checkers should be given responsibility for checking outputs.
They must follow your disclosure control process and will be responsible for any automated parts of this process.
Output checking can help mitigate against unintentional data disclosure or leaks. | Mandatory | 1 | See 3.3.3 | |
| 3.3.5 | You must have a documented policy for handling disclosure risks associated with any outputs that cannot be manually checked. | Some categories of output, for instance binary files or very large numeric files, can be difficult to manually check.
If egress of such files is permitted then the risks of inadvertent disclosure must be mitigated and documented.
Refusing to allow egress of such files is also a valid policy decision. | Mandatory | 1 | See 3.3.3 | |
| 3.3.6 | You should have a statistical basis to guide the decisions of an output checker on the safety of outputs. | There should be a solid basis to allow decisions to be made about data based on risk factors such as re-identification of an individual or risk to commercial operations posed by outputs from the TRE. | Recommended | 1 | The outputs are at the project level. Only people within the project (and not the TRE platform) can access these. The TRE Platform is not able to access the data within the project (apart from via a sys admin account) | |
| 3.3.7 | You could create a semi-automated system for checks on common research outputs. | Automation helps make decisions on outputs more consistent and reduces the overhead for output checkers.
It’s unlikely however that a fully automated output checking system (without humans in the loop) would be appropriate, given the risks associated with accidental data disclosure. | Optional | 1 | We do not see this as necessary. But it could be useful to train project people in good handling of data. | Look at providing automated tools to help with training of project members who are involved within a new project TRE. |
| 3.3.8 | TRE outputs should be limited to the minimum required for sharing results of any analyses. | This decreases the risk of inadvertent disclosure, and makes it easier to comply with data protection legislation (e.g. GDPR). | Recommended | 2 | Research scientists would / should do this naturally. Principle Investigators and senior science leaders should / would review such outputs as part of the publication process and activity. | |
| 3.4.1 | You should provide a metadata catalogue of available datasets for users. | This is particularly relevant for TREs with population-level data collection of general interest.
This may not be appropriate for TREs where each project has its own data sharing agreement with one or more data provider or very sensitive datasets. | Recommended | 2 | In these project TREs it is the project that is making the data available to their project people (users) therefore this is redundant. No other party can see the any of the project data except those seeing outputs from the project. The project controls all of these. | |
| 3.5.1 | You must be able to specify what categories of data your TRE is able to support. | Your TRE must provide an explanation of the kinds of data it has been designed to hold, with reference to its security capabilities, that can be understood by all stakeholders.
Relevant stakeholders may include information asset owners and project teams and they may have different levels of technical expertise. | Mandatory | 2 | All categories of data can be supported, as the project TRE is built to the specification covered by the legal agreement (and ethical and financial ones). | |
| 3.5.2 | Your TRE could support projects with differing security requirements through configurable security controls. | This allows projects with different security requirements to each be met with a suitable level of controls.
It helps ensure that users can work effectively, with minimal barriers. | Optional | 2 | It is not clear what this means. Not all projects have to have a 27001 / HIPPA compliant infrastructure, but they all have to comply to the standard model for the project TRE capabilities and roles. | |
| 3.5.3 | Your TRE could offer a pre-defined set of security control tiers. | Security control tiers can be designed to cover the types of project or data you expect to handle.
Projects may be placed into the most suitable tier rather than having a bespoke design.
This reduces the number of unique configurations that need to be supported. | Optional | 2 | There seems no need to provide additional security for different projects beyond 3.6.2. | |
| 3.6.1 | You should have a consistent and easily accessible meta-data data model or similar to describe what a data asset contains. | Where possible, existing data models should be employed (and extended if necessary).
More detailed information on the data schema for data assets should also be provided to assist researchers in understanding what data may be available without the need to see the underlying data. | Recommended | 2 | Each project TRE decides what data they bring in, stores and then creates within their project. There is no concept of a data catalogue as each project is its own TRE supported by the common TRE platform. However the common snowflake metadata model creates a view of all tables, columns and rows (names, data format and optional description comment)
Only if Secure Data Environment (SDE) data was needed by a project would it be relevant to have access to a the metadata model from that SDE so that the project could develop its research. | |
| 3.6.2 | You could provide summary, abstracted or synthetic data to researchers without exposing the underlying data set. | To reduce the need for access to row level data researchers could be provided with non-sensitive versions of the data either as summary data or using synthetic versions of the data for activities such as code development and cohort planning. | Optional | 1 | We see no need for this. All project TREs are unique and self defining. Only if Secure Data Environment (SDE) data was needed by a project would it be relevant to have access to a synthetic set from that SDE so that the project could develop its research. | |
| 3.7.1 | You could provide an interface application for data consumers and data subjects to query elements of the data. | In order to make data findable, an application which queries the meta-data or elements of the research data could be made more easily accessible than the data itself. | Optional | 1 | Not applicable as all project TREs are unique and specific to the project- no other party has access. | |
| 3.8.1 | Archived data within the TRE should be read only. | Archived data by its very nature should not change and therefore be maintained as a read only store.
If an update is required, it may be pulled from archive into a separate operational store. | Recommended | 1 | Data held by a Project TRE that is no longer actively needed could be archived using common database type actions (partitioning off, using time travel clone facilities, or just moving to an alternate table). Alternatively the ARCHIVE process offered by the platform TRE (TRELLIS) enables defined sets of data to be put into a file storage format in an S3 bucket inside the project for later removal. | |
| 3.8.2 | Long-term archives must be held in simple, standard formats to ensure accessibility. | Some data archives may be required by policy or legislation to be kept for very long periods within the scope of the TRE.
Such data should be held in the simplest possible file format, conforming to international standards if available, to ensure they are platform and application agnostic. | Recommended | 1 | No long-term archives are held by the platform TRE (TRELLIS) and all projects once completed / ended will be deleted (except metadata) after an archiving process for that project. | |
| Item | Statement | Guidance | Importance | Score | Response | Improvements |
|---|
| 4.1.1 | You should have a business continuity plan that includes consideration of loss of service for deployed TREs. | This may be due to downtime from service providers, a breach, or loss of power.
Your plan should detail your process for managing loss of service for deployed TREs, and evaluation of impact of such loss. | Recommended | 2 | There is a full service recovery plan built into the service management of the Platform TRE TRELLIS service | |
| 4.1.2 | You should regularly test the aspects of your business continuity plan concerning TREs, and have a process in place to iterate the plan if required. | 0 | Recommended | 1 | The testing of the recovery of one or all projects has not been completed as yet. The cloud nature of the solution would require this to be done on test rather than production versions. | |
| 4.2.1 | You should ensure that all projects using your TRE have a named project manager. | The project manager has responsibility to ensure the smooth running of the project.
Their responsibilities may include budget management, tracking TRE status, managing communications with the TRE operations team, and other project support tasks. | Recommended | 2 | All project TREs are led by the project Principle Investigator, and are created with that person registered. | |
| 4.2.2 | You should not give project managers direct access to the TRE. | Doing so ensures a separation between those able to access sensitive data, and those overseeing access to sensitive data. | Recommended | 2 | No person has access to the project TRE configuration and no one can invoke any action except through the specific five roles covering the chain-of-custody from loading to investigator/experimenter activity. | |
| 4.3.1 | You must document all features of your TRE implementation. | This includes ensuring all documentation is discoverable, clear, and able to be easily updated based on stakeholder feedback | Mandatory | 2 | This is covered by slides and architecture documents | |
| 4.3.2 | You should have an education programme in place to upskill stakeholders in the use and management of your TRE. | This may include learning modules, workshops and other resources on how to effectively access and use a TRE, FAQ pages, and accessible pathways for additional support | Recommended | 1 | Training on use and explanation of chain-of-custody roles is available. | Enhancing the training and epxlanation material is underway. |
| 4.3.3 | You should periodically carry out a training needs analysis (TNA) for all stakeholders included within your TRE provision. | At least once every 12 months you should assess the training needs of your stakeholders, and ensure they have easy access to all required training materials | Recommended | 1 | Project TREs have the ability to raise service requests and these ca be used to identify generic areas of misunderstanding to be addressed through FAQs or more formal documentation training. | |
| 4.4.1 | You must ensure that all projects using your TRE are aware of any associated costs and are able and willing to pay them. | Costs may include provision of the underlying TRE infrastructure, additional resources required in a specific TRE (for instance memory or additional compute), hardware including managed devices, and staff support costs | Mandatory | 2 | No Project TRE is created wihtout legal afgreements and finiancial approvals. These financial budgets are then allocated for each participating Research performing Organisation for each chain-of-custody role they adopt. | |
| 4.4.2 | You should be able to track the costs associated with each TRE project. | This includes knowing which costs are associated with which project, and having an appropriate charging mechanism in place in line with your organisational policy. | Recommended | 2 | Audit and compliance reporting covers costs by project and across the platform. | |
| 4.4.3 | You should have a process in place to ensure your TRE provision remains financially sustainable. | This could include having a cost recovery process in place, or setting up a long-term funding mechanism to support projects with TREs.
At any given time, you should have funds free to cover all potential foreseen TRE provision for at least 12 months. | Recommended | 1 | Normal account administration activiies exist to map actuals and budgets. | Developing invoicing and accounts receivable capability will connect the end-0end finacial models underpinning this TRE platform. |
| 4.4.4 | You should minimise the cost of your TRE infrastructure wherever possible | You should have regular reviews of your TRE provision and actively work to bring down costs, streamline provision, and optimise support. | Recommended | 2 | Normal supply management negotiations | |
| 4.5.1 | You must identify any goods or services that will be needed to operate the TRE and ensure that a plan is in place to purchase them as needed. | These may include computing hardware, cloud credits or devices through which users access the TRE. | Mandatory | 2 | see 4.4.4 | |
| 4.6.1 | Your TRE must have a team of Operators in place to support projects working with TREs. | This may be part of your organisation’s IT support team, or separate.
Responsibility should be clear and stakeholders should easily be able to access support appropriate to their needs. | Mandatory | 2 | This is formally not allowed wihti the TRELLIS platform. No project TRE can operate a second TRE wihtin itself. Therefore this does not apply.
All project TREs can call on a central team to support them and can access a service portal to reconfigure (after approval) collaborators, budgets, users and roles, and experiments. | |
| 4.7.1 | You should have a clear process in place for stakeholders to feedback on your TRE infrastructure. | This may include a GitHub repository where people can open issues and discussions, communication streams like Slack or email, or forms stakeholders can fill in. | Recommended | 2 | Feedback channels exist through the projec lead, the Crick ITO service ticket system and through engagement sessions with the projects themselves. | |
| 4.8.1 | All public engagement activities must include a range of perspectives and be inclusive (*optional for TREs without personal data). | Any public engagement activity carried out by TREs should involve diverse participants and that activities are accessible.
Recruitment plans should consider how to proactively reach a representative sample of people or target particular groups of people where relevant
This could include following guidelines such as PEDRI. | Mandatory* | 2 | Where public bodies are involved in the project then this will happen by default. The TRELLIS platform has been described and shared in community events. | Further opportunities to share this platform and its model of operation are continually being proactively identified and engaged with. |
| 4.8.2 | Details of TRE operations, data available and projects which have accessed the data should be publicly available (*optional for TREs without personal data). | TREs should be as transparent as possible by providing information online.
Where information is made available online this should be written in clear language understandable to general public.
A record of projects which have accessed data via the TRE should be kept and made available.
Where possible it should include name, summaries, public benefit (if relevant) and organisations involved | Mandatory* | 2 | This is true only where the project wishes their Project TRE to be discussed publically. It is their facilities and they can chose whether they speak externally about it.
TRELLIS as a service will be included in grant applications and so where these are publis the presence of the Project TRE wil be assumable. | |
| 4.8.3 | Members of the public should be included in TRE operations and/or oversight (*optional for TREs without personal data). | Members of the public can be involved via presence on steering groups or project approvals panels.
Alternatively TRE’s can establish separate public panels available for both researchers and TRE staff to consult. | Mandatory* | 2 | Not aplicable for project TREs but the individual research perfroming organsiations can do that independently in advance of enageing with the project and when deciding what data to share into the project. | |
| 4.8.4 | You should publicly share details of incidents, near misses, and mitigations in a timely fashion, in line with good practices for responsible disclosure. | This may be via the TRE website or annual reports.
Sharing this information is particularly important when a TRE holds public sector data. | Recommended | 1 | It is the projects which have accountability and responsibility for disclosure. As the platform would be involved in any such investigation, anonymous collection of any event would allow the TRELLIS platform to provide some general statistics | As the platform matures with more users, the collection of anonymous data of any event could start and this would allow the TRELLIS platform to provide some general statistics |
| 4.9.1 | You should identify areas where legal advice may be required and ensure that you have ready access to it. | It is likely that legal advice will be necessary for several issues around the handling of sensitive data, and managing project contracts.
TRE operators should have ready access to legal advice, including a way to solicit advice and carry out associated actions. | Recommended | 1 | Legal teams are always directly connected to projects that are to have a project TRE. | |
| 4.9.2 | You should identify areas where advice on data protection issues may be required and ensure that you have ready access to it. | It is likely that data protection advice will be necessary for several issues around the handling of sensitive data. | Recommended | 2 | All project TREs which the Crick contributes data to have a DPIA stage of consideration | |
