Eastern England SDE
August 18, 2025
Table of contents
More information can be found on the Eastern England SDE website .
Information governance
| 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 | We systematically gather and monitor information governance requirements from relevant legislation (e.g. UK GDPR, DPA 2018), contractual obligations, and ethical standards. These are reviewed regularly to ensure that the SDE’s controls remain appropriate and aligned with evolving legal, regulatory, and ethical expectations | |
| 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 | We implement controls in a systematic and structured manner, directly aligned with identified legal, contractual, and ethical requirements. These controls are mapped to specific obligations and reviewed regularly to ensure ongoing compliance and stakeholder assurance | |
| 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 | 2 | We have dedicated staff in place to ensure that information governance controls are appropriate, implemented effectively, and enforced. Resourcing is proportionate to the scale and complexity of the SDE, with ongoing investment to support compliance and continuous improvement | |
| 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 | SOPs and policies can only be updated by designated members of the SDE team. SOPs and policies are kept up to date and relevant to the SDE. | |
| 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 | 2 | Polciies and SOPS are versioned and tracked documents in Confluence | |
| 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 | 1 | We have no regular reporting as yet. | As part of our ISO127001 certification and engagement with the SDE network we are improving our reporting and establishing appropriate processes for regular and review and quality management |
| 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 | 2 | Yes, ISO27001 and DSPT | |
| 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 | 2 | We will report when there is a need. | |
| 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 | Contracts include details of requirements for all access to the SDE and security requriements | |
| 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 | Changes to the platform are agreed in regular meetings with third parties. The SDE team maintain the overall security perimiter unless specific requirements prevent. | |
| 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) | NA | ||
| 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 | JIRA service desk is used to track security incidents and resoluition, along side CUH escalation/reporting where relevant. | |
| 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 | 2 | Incident response plan includes process / technical feedback and improvement processes. | |
| 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 | Data QC is embedded in the data transformation processes generating reports. Tooling deployed within GDPR boundary of data provider provides high level information. Utility of other dashboards will be assessed based on user feedback, not built without a direct requirement. | |
| 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 | N/A | ||
| 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 | We have a risk scoring matrix for evaluating impact and likelihood. | |
| 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 | 2 | The SDE complies with HRA guidance that DPIAs are not requried for specific projects. A data processing assessment is embedded within the structures of the SDE, including our REC and CAG approvals. Where data contributors require a DPIA, we support them with this. | |
| 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 | 2 | We have a defined process for designing, implementing, and recording risk mitigations following risk assessments. Mitigation strategies are developed and implemented during monthly risk meetings, and actions taken are documented in the risk register, including responsible parties and timelines. The effectiveness of these mitigations is reviewed regularly, and adjustments are made as necessary to ensure continuous improvement. | |
| 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 | 2 | We have a defined risk management structure with clear roles and responsibilities. Risks are owned at appropriate levels, with operational risks managed by designated leads and strategic risks escalated to top management. Escalation pathways and delegation processes are documented to ensure timely and proportionate responses. | |
| 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 | 2 | Our organisation understands its risk appetite, which is reflected in our risk management process. Risks are assessed and owned by relevant stakeholders, with mitigations put in place where necessary. In cases where risks fall outside the acceptable appetite, we have a process for escalation, allowing for informed decision-making regarding whether to accept the risk or implement further controls. This ensures that we manage risks within the defined appetite and are prepared to make adjustments as needed. | |
| 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 | As part of our approvals process, contracts are put in place with organsiations requesting access to data in the SDE, including funding responsibiltiies. Responsibilties concerning data handling are address through technical controls in the SDE and contractual controls as part of the approvals process. | |
| 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 | Contracts tracking is the responsibility of CUH. Researchers and their employing organsiations are responsible for informing us if those accessing data leave their organisation. | |
| 1.4.3 | You must have checks in place to ensure that changes in regulations are met for a project. | Mandatory | 2 | CUH have an R&D team who ensure theya re up to date with changes in regulation and will ensure any changes affecting the SDE are enacted | ||
| 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 | 2 | An off-boarding process exists for users and data. Data retention is automated as part of project lifecycle - agreed at project initiation and reviewed at project end. | |
| 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 | 1 | Management of data, users and airlock following project acceptance is via automated workflows which feed into a JIRA ticketing system to highlight action points. End of project notifications are not implemented as yet. | |
| 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 | Details are held across various formats including the data access request form, public data use register and the SDE platform. Changes to user access and data retention are also held in the SDE platform as part of the project configuration. | |
| 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 | A public data user register is available on the EoE-SDE website detailing all projects. | |
| 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 | Memebrs of the SDE team will either be CUH employees or have appropriate research passports before accessing sensitive data. | |
| 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 | 1 | Members of the SDE team are requried to undertake CUH mandatory 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 | Role based access manages engineering, data management, audit and researcher roles | |
| 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 data controller delegates this authority to the CUH as the host organisation. Data access decisions are made through the SDE data access committee. | |
| 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 | Platform access via SSO+MFA, VDI sessions protected by additional user/password when locked (independent from user device screen lock). Ingress of non-standard tool will be reviewed. | |
| 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 | User is identified by SSO email account, tracable through entire system (indirectly in platform logs). | |
| 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 | 1 | Training plan for all roles is being generated. Members of the SDE team are requried to undertake mandatory CUH training, including around GDPR. | |
| 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 | 2 | CUH mandatory training is available and recorded through DOT. | |
| 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 | CUH mandatory training must be repeated at Trust defined intervals (e.g. annually) | |
| 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 | CUH mandatory training is available and recorded through DOT. | |
| 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 | 1 | In additition to CUH mandatory training, we aso accept training from trusted third parties (e.g. MRC GDPR coruse). | |
| 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 | DOT is used to track CUH mandatory training | |
| 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 | N/A | ||
| 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 | N/A | ||
| 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 | N/A |
Computing technology and Information Security
| 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 | 2 | VDIs do not allow data to be copied out of the session using the clipboard | |
| 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 | Virtual Desktops are Ubuntu with Jupyter Notebooks (bash, Python, R), RStudio, DBeaver (database access for Postgresql) and LibreOffice as the core software stack. | |
| 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 | N/A | ||
| 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 | Virtual Desktop can be opened in a new browser tab. Option to download DCV client app (user space) and use this to access Virtual Desktop for a cleaner exerience. | |
| 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 | 2 | Documentation in place for basic usage of platform, tools and local database access. Airlock documentation for initiating ingress and egress of data or code is available. All documentation is available via the service portal in a Knowledgebase managed under Confluence. | |
| 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 | Regular updates to software stack, often linked to RES upgrade process. | |
| 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 | 1 | RES has a common readwrite/shared folder common to all users in a project. Users also have private storage. LibreOffice is available for development of documents within the project space. A git based code repoistory can be made available for all projects, alongside any repositories that have been ingressed. Shared project databases are on roadmap. | |
| 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 data and infrastructure for a project has a dedicated security group and encryption key. VDI sessions are specific to project, user "home" is specific to research project. Shared space for all users of a project is limited to the project boundary. | |
| 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 | 2 | Needs for external licencing will be assessed on a case by case basis. Default stance of platform is to block all internet access. | |
| 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 | 2 | Programming languages: Python, R, bash scripting in system and Jupyter terminals Jupyter Lab and Rstudio apps Libre Office apps Instance specific Postgres DB & DBeaver | |
| 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 | Preparation of data is via code repository paired with code pipelines. No ETL is able to move to research environment without a specific linked commit and pipeline execution. Researchers are provided with git tooling and ability to work with local pipeline tools such as Nextflow based on project requirements. | |
| 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 | Internal CRAN mirror, no direct access to public R repositories. PyPI artifact repository for pull through access to packages with ability to block specific packages. Minimises disruption to researcher when adding packages. | |
| 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 | Changes to system level packages (admin permissions) are limited to administrative build of a software-stack following review of risk. Items outside of CRAN/PyPI require the same process. Use of tooling held in "resercher" code repositories requires high level review and approval for pull into the environment, including virus/vunerability scanning. | |
| 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 | No HPC facility at this time, GPU can be made available, but distinct to project. | |
| 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 | 0 | Future aspiration | |
| 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 | 1 | GPUs can be authorised for a project on case by case need. | |
| 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 | 1 | Postgresql database is available for self admin on VDI instance (user & project specific). Working towards shared instance within project. | |
| 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 | N/A | No Big data frameworks available | |
| 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 | Infrastructure is deployed by using IaC. Project specific infrastructure is driven by project configuration triggering pipelines to apply changes. Where IaC is triggered manually detailed documentation is in place. | |
| 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 | We have made a significant investiment in use of IaC and deployment pipelines | |
| 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 | Changes to deployed infrastrucutre is via IaC and code pipelines. Changes have enforced review and approval requirements along with branch protection. Updates to research project use cases and membership have change control via the DAC process. We have ISO27001 certification which will monitor our adherance to this. | |
| 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 | We have a 4 tier deployment, Dev (minimal retrictions), Test, Stage and Production | |
| 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 | Change to deployments is via merging of code into relevant deployment branches and code pipeline deployment. Merge requires review/approval for each stage of propogation dev->test->stage->production | |
| 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 | Close down of project infrastructure follows a documented and semi-automated process. Elements of infrastructure for a project can be removed at different stages of lifecycle. E.g. data-landing-zone for source data can be closed once data trasferred by modifying a flag in project entry, enhancing security of platform. | |
| 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 | AWS provide significant information of the availability of systems via the AWS Artifact service. Critical components such as object storage have 99.99% availability and eleven 9s durability. | |
| 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 | The SDE provides a business hours best efforts support framework. This is clearly laid out in the terms of use. | |
| 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 | The platform utalises a multi account and network segregation model to manage high level data classifications * Data Landing Zone - drop off of data, to be scanned and validated against encrypted checksum and manifest * Data Intergration Platform - Successful data from DLZ ready for any ETL or other manipulation. * Project Research Environment - Research ready data. Within each area data is further segregated by security group at the project level. The overal network security stance is managed by IaC under the AWS Landing Zone Accellerator - A foundational compliance framework incourporating controls as defined by NCSC. | |
| 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 | The research space is segregated by project. A researcher with access to two projects is not able to access data from both symultaniously. Home directories are segregated by project also. Researchers within the same project are not able to access each others VDI sessions, but can share data through a shared drive to facilitate collaboration. | |
| 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 | All outbound connections are heavily restricted. Limited routes are available to support authentication requirements for the airlock application. | |
| 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 | AWS Guard Duty and Security hub automatically flag potential issues. S3 buckets have automatic remediation for SSL, but all reports are incorporated back into IaC. Vunerability scanning of data is built into all data ingress processess. We commit to annual penetration and vunerability testing as part of our commitments under ISO27001. | |
| 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 | AWS Guard Duty and Security hub are active systems which feed into our service delivery platform for events triggered. | |
| 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 | Users, projects and workspaces are embedded in our project configuration database. We are able to generate "data volume" outputs for various states. The EoE SDE is a data mesh and primarily stores project specific datasets formed for a specific limited purpose. Static datasets are tracked by the wider SDE team. | |
| 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 | This is embedded in our project configuration database, as well as a public data user register. | |
| 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 resources available to the project space are associated with configurable budgets, additionally we are able to drill into any project costs down to the individual service level, e.g. S3 storage or compute costs. | |
| 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 | Applicants are advised as to the costs associated with the compute and storage based on a described use pattern. The EoE SDE operates on an on-demand basis with users able to stop, start and resize instances (within limits) to minimise costs. Additionally the agreed budget is tracked (monthy & total spend) with automatic notifications to nominated members. | |
| 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 projects undergo a technical feasibility process prior to any data applications been made. | |
| 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 | The EoE-SDE operates on an on-demand basis, researchers are able to initiate instances provided they do not exceed defined budget constraints (controlled in platform). Persistent storage in the research space is elastic. All support querys are routed through a Service Delivery Portal for assessment. | |
| 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 | All projects have a budget attached with automated reporting of utalisation. The SDE as a whole has a monthly budget notification. High level SDE costs are presented on a weekly basis. The platform also reports detection of cost anomaly events (sudden increase in traffic or storage costs) into our service delivery platform as an early warning. | |
| 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 long term infrastructure (core or project) is managed by Infrastructure as Code paired with design, deployment and modification guidance documentation. Changes follow a code and security review then sign off process. | |
| 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 | 1 | Infrastructure is IaC, working towards automation of VDI software stack builds. | |
| 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 | All IaC deployment pipelines include "dry-run" and approval stages. | |
| 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 | 1 | Methods exist, but not regular in nature. Project deployment stack validates all projects on each execution. IaC stacks can be triggered to highlight drift from intended states. Access controls prevent manual manipulation of network level configuration only possible via IaC deployment pipeline. | |
| 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 | A project environment can be restored to a compliant state by re-executing the deployment pipeline. Ability to modify a project environment is heavily restricted in production. | |
| 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 | Data in object store is versioned. Shared data and home directories are protected by snapshots. All are encrypted under the project keys. Retention periods are agreed by the DAC process and embeded in the project setup configuration. | |
| 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 | 2 | Infrastructure benefits from a 2 availabilty-zone depoyment, multi-region is not possible due to data residency limitations. Some core elements require a switch over phase. A VDI session is not resilient, however the underlying data storage (shared/home) is. All persistent data for the wider platform is highly resilient and durable. | |
| 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 | 1 | All infrastructure as code and configuration is held in a code repository or data repository. Project level configuration is in need of formal back up process. Some risk outstanding with manual configuration of EntraID. | |
| 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 | Proceedures for breach containment, reporting and remediation plans are in place as part of ISO27001 compliance. | |
| 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 | Planned, not tested. | |
| 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 | 2 | AWS Guard Duty and Security hub are integrated into our service desk for wider visibility and assessment. | |
| 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 | 1 | Where possible managed services are employed to minimise patch and security management. For systems under our remit we track required upgrades and apply updates on an as needed basis based on urgency and risk. Working towards a more pro-active approach for VDI software stacks. | |
| 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 | 1 | Significant isolation of infrastrucutre reduces risk, some elements require managed deployment and validation in non-production environments (research enginnering studio, airlock) preventing full automation. | |
| 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 | 2 | We have committed to annual penetration and vunerability testing of the SDE as part of ISO/IEC 27001. Additionally major changes to infrastucture may trigger an assessment. 2 penetration tests have been completed to date. | |
| 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 | 2 | All findings of tests or automated alerting are assessed for impact and validity in context and appropriate remediation applied. These are discussed at ISMS meetings. | |
| 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 | Plan has been shared via PPI/E and CAG engagement, but not accessible without direct enquiry. | We will review website plans and look for a suitable place to add dates and highlevel summary of pen/vun test |
| 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 | All data is encrypted at rest. Each project has independent encryption keys, managed by SDE team (using AWS KMS, but not auto assigned). | |
| 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 | All data is encrypted in transit with TLS encryption. To ensure no tampering of source data occurs a private key encrypted checksum of each data file is included in a structured manifest. Files not listed in the manifest are not moved beyond the landing zone. Each files checksum is validated and then the files scanned for vunerabilities and viruses. For researcher ingress/egress the same rules apply, with the execption of formal manifest as files are selected individually. All VDI sessions are over https. | |
| 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 data is encrypted in transit within the TRE with TLS enforced on all S3 requests. Automatic remediation and alerting should an S3 bucket be created without this enforcement is in place. | |
| 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 | Encryption is managed by AWS Key Managment Service. Software under the responsibility of the SDE is minimised to reduce risk with security update end dates tracked both by the team and highlighted by AWS service monitoring notifications. | |
| 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 | AWS KSM is used for key management. User access is via insustry standard SSO with MFA enforced. Members of the SDE team use tooling from "Keeper Security" for one-time-shares where necessary (setting up data providers etc). | |
| 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 | N/A | Cloud first, "screenshot" is deemed acceptable risk as data is anonymised before access. | |
| 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 | NHS DSPT, ISO/IEC 27001, CAG approval obtained |
Data management
| 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 | We have established robust processes to assess the legal and regulatory implications of handling data throughout its lifecycle. We comply with UK GDPR and have obtained Section 251 approval from the CAG to ensure that we process the appropriate data categories. Privacy notices are published on the data controller’s website, ensuring transparency with data subjects regarding their data usage. We implement PET security controls to safeguard data, and a comprehensive DPIA is being conducted to identify and mitigate any risks associated with data processing. | |
| 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 | 1 | We document all data handling decisions through our Data Access Committee, which makes decisions publicly available. We use Confluence and Microsoft 365 with strict version control for project documents, and meeting minutes are kept to record key decisions. Internal audits are conducted regularly, and we have clear processes for data retention and deletion, ensuring transparency, accountability, and compliance. | |
| 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 | 2 | Data are classified by the utility, sensitivity and intent. Project data is provisioned for the specific research interest. SDE assets may be suitable for linking with research data, or general reference access. A cataloge of items not specific to a project is maintained with relevant information pertaining to access and sensitivity. | |
| 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 | 2 | Data can only be provisioned into the SDE by knowledge of the platform team. Prior to setup all IG and DAC documentation must be in place. Routes to send data are opened only when data is expected. Data recieved not specified within a manifest does not enter the integration platform. Ingress routes are closed once data is received. | |
| 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 | 2 | The platform has a "2-pairs of eyes" process for output checking and adheres to a general rule of "non-disclosive" summary outputs. This is supported by SACRO tooling to focus attention to areas of concern. Where there may be a need to allow more granular details to flow this is agreed by the DAC, in advance and documented to ensure a streamlined process. Should there be a research need for granularity not agreed in advance this will be taken up with the IG leads and DAC. | |
| 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 | All data egress is controlled by the SDE data team, delegated by the data controller CUH. | |
| 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 | All data egress is assessed by the SDE data team, not members of the project team. The data team reserve the right to request additional support for specialist outputs. | |
| 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 | The SDE maintains records for different audiences. A Public Data Use Register (PDUR, current and past SDE projects, website), Research Assets (reusable, internal), Datasets (HDR-UK portal). | |
| 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 | 1 | The project documentation captures project end dates and retention periods. A process exists to close down projects (ending easy access) as well as removal of project data. The PDUR includes project end date, but not agreed retention periods. | We will review the data use registry fields and assess if it is appropriate to specify retention periods |
| 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 | Deleteion of data can be verified via cloudwatch logs. | |
| 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 | All input data can only be processed via ETL pipelines which are backed by a git repository. Only data processed by this route can be progressed to the research space. | |
| 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 | All movement of data between local and remote is heavily restricited. Copy into the remote session is permitted for a limited number of characters (512) to support secure passwords and small codeblocks. Copy from the remote VDI to local environment is blocked. Communicatrion between the local computer and remote VDI is blocked for web-cameras, microphones, USB devices and printers. Only mouse/touch/stylus are permitted as input devices. | |
| 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 | The East of England SDE uses a data-mesh approach to only bring in data specific to a research question at project initiation. No aggregated data lake is held locally. Within a research space only data for the specific project exits. | |
| 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 | Shared/service accounts are not permitted by the user agreement. | |
| 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 | 1 | Accounts are only granted following an organisation in good standing approval. No personal email is permitted when signing up to the SDE. | We plan to move to use the HDRUK safe-people-registry |
| 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 | Individuals are only granted access to data relevant to the research project they are assigned to, all other data is inaccessible. If a user is assigned to multiple projects in the environment the compute is specific to an individual project preventing cross-linking. | |
| 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 enforced on all accounts granting access to the platform, user & engineer. | |
| 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 | SSO is available for all able to use this. In some edge cases the SDE may be required to generate a sde specific login (Microsoft Entra). The VDI instances have a separate dedicated password to allow password complexity and rotation orthagonal to the users organisation. | |
| 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 | We have the ability to apply this level of restriction, however this is intended to be applied at a country level rather than individual institution. | |
| 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 checkers use the SACRO software and researchers are trained in it's use during the development of outputs. We are active members of this space generating documentation and feedback as well as piloting SACRO-ML. Maturity in this area is growing with continued involvement with the SDC (Statistical Disclosure Control) comunity. | |
| 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 | Anticipated outputs are a component of project approval and are part of the DAC approval documentation. | |
| 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 | SACRO documentation along side more general disclosure control concepts are in place to support validation of outputs. This is being expanded as part of maturity work | |
| 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 | 2 | Airlock requests are assigned to a specific member of the data team for checking. This will be tracked in our Service Management platform, along with the second review. | |
| 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 | The need to egress binary data will be heavily challenged. In the case of trained models we are working with SACRO-ML to minimise risk of training data being embedded. Large numeric files will be subject to SACRO evaluation and challenge as to the need for egress. Maturity in this area is growing. The SDE aims to not have a blanket ban, but assess requests on merit. It should be also noted that the data presented to researchers will have a minimim k-anon applied and AWS MACIE reports are generated. | |
| 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 | 2 | SACRO is used to assess risk of loss of anonyminity within an output. It should be also noted that the data presented to researchers will have a minimim k-anon applied. | |
| 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 | SACRO is being used to assess outputs, this is a maturity item and some buy-in of researchers is required for greatest impact. AWS MACIE is also in place to highlight potential disclosive leaks. | |
| 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 | Researchers have access to shared project space and are able to screen share. This will minimise requests to egress data. | |
| 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 | 1 | Datasets are published via the HDR-UK gateway, metadata is of varying depth. | |
| 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 | Types of data available are detailed on the the SDE website. | |
| 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 | N/A | ||
| 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 | N/A | ||
| 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 | 1 | OMOP CDM is used to provide cohort discovery and also as optional delivery format. Meta-data for reusable assets are described on the HDR-UK portal. Due to the nature of data-mesh implementation bulk of data is specific to usecase. | |
| 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 | Count based cohort discovery is available to separate researchers from data during planning. PET tooling allows a tunable k-anonyminity level. By default row-level research datasets will adhere to k-anonyminity, however more granular access can be obtained as part of the DAC approval process. | |
| 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 | Count based data for the purposes of cohort discovery will be available via the HDR-UK portal. The same portal will include meta-data interfaces. Data Managers will have the ability to access a graphical interface to refine queries with a researcher. | |
| 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 | 2 | All data is versioned in the environment. A request to modify a finalised dataset would require a new project identifer resulting in a requirement to mirror data to a new research project. | |
| 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 | Archival will be via the most cost effective method, this is generally some form of simple flat file, even for data best accessed as a relational database. Where possible an appropriate model will be used. |
Supporting Capabilities
| 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 | 1 | The TREs are fault tollerant over 2 availability zones (AZ) with a minor requirement for users to start a new VDI instance. Underlying storage is tolerant to loss of an AZ. AWS services are highly resilient, however provider or engineering configuration error or failings resulting in a breach remain an ongoing threat to service. This area is undergoing development as we approach maturity. | |
| 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. | Recommended | 1 | Multi environment deployment ensures that we are regularly exercising deployment and upgrade of major components of the platform. We are in th process of deploying a parallel implementation to replicate a ground up build to ensure additional resilience. | ||
| 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 | The operations team has a project success manager and service desk representatives. Each project is assigned a project manager to shepherd the project to success. Budget alerts are propogated to both the project lead and the service delivery team. | |
| 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 | Only researchers are granted access to the provisioned research space once configured and data is provisioned. Data Managers have access to the data integration zone, data still segregated by project. Select Admin Engineers have the potential to access all areas, however elevation of priviledges would be necessary to decrypt data - this results in alerts in our service platform. | |
| 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 | All features are documented for deployment, operations and security elements of the platform. Primary documentation is via Confluence, allowing versioning and accountability. User facing documentation is available for all members of the platform via a Confluence Knowledgebase - access is restricted to those on-boarded to the platform. This evolves based on user feedback. | |
| 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 | 2 | An extensive knowledgebase is in place for research users to consume. This is being expanded at all times based on feedback. A Service Desk is available for items not covered, this is integrated with the knowledgebase, allowing for articles to be highlighted when creating a ticket to sign post users to self-solve. | Workshops have been discussed especially on how storage and compute type impact I/O and CPU through put |
| 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 | 0 | Expect high turnover, this doesn't appear a good use of resource. safe-people-registry aims to surface source insitution training/certifications. | |
| 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 | Each project has a budget attached and emails are triggered to both the lead researcher and the SDE serviece desk at 50% / 80% of monthly and annual budget consumption. These are available to platform administrators and used for both show and charge back. Outside of consumable budget project startup costs are agreed prior to initiation of data collation. | |
| 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 | All research facing resources are tagged to allow for generation of reports and invoices. | This will be expanded when "organisation" resources are implemented. |
| 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 | The financial model for the SDE is an evolving element of our maturity. A costing model has been developed to charge for projects accessing data to cover operational costs along with a pass through on researcher compute and storage. This model is undergoing testing with some current use cases. Core funding has been received to date, and we are expecting confirmation of funding continuity over the coming months, with a transition towards a longer term funding model. | |
| 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 | Platform costs are reviewed on a weekly basis, with a monthly rollup of the prior 5 months for context. Increases/decreases are discused and evaluated for optimisation. SDE admins have visibility of user instance utalisation to highlight unused hardware. | Working to implement scannning of platform for less obvious costs such as orphaned infrastructure/keys in development accounts. |
| 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 | As a cloud platform all costs are on a PAYG basis, however we work with AWS to identify credits for R&D purposes as well as having obtaining an OGVA2 agreement to reduce costs and add benefits | |
| 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 | The SDE has 2 skilled teams to support the projects and platforms, DataOps and DevOps. Each team has cross cover and a breadth of skills. We manage workload via a service desk and JIRA. | |
| 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 is primarily via two routes. Service Desk and shared mailbox. Items received via mailbox are converted to service tickets on the requestors behalf. | |
| 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 | We run a public survey each year which seeks to reach a diverse demographic which we also quantify. Targeted engagement of underrepresented communities has been undertaken to foster their trust and engagement with the SDE. We have a group called the Core Public Advisory Group which is made up of public representatives with a lived experience and those with a professional background to foster co-production and co-design of the issues we discuss and the solutions for these. We use the PIRIT Impact Tracker to help track the impact of our PPIE activities and actively participate in Communities of Practice focused on PPIE and Comms & Stakeholder Engagement All of our work is underpinned by the NIHR UK Standards for Public Involvement and we are also following the PEDRI Good practice guidance for public engagement which ensures that ensures that we seek to ensure our public involvement is meaningful, ethical, and effective. | |
| 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 | A Public Data Use Register is maintained on the EoE SDE website. | |
| 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 | A Core Public Advisory Group is in place which is made up of public representatives who are residents of the east of England who have have volunteered to take part. | |
| 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 | This will be reported through the lead organisations escalation and incident reporting process. This is being matured as prt of ISMS implementation. | |
| 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 | 2 | Legal and contract adivce is available both through internal legal counsel at CUH and through Information Governance Services (IGS). | |
| 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 | Support around data protection issues is provided through expertise within both the Health Innovation East and CUH teams. We can also draw on the services of IGS. | |
| 4.9.3 | You should identify who will be responsible for managing contracts related to the TRE. | These contracts may include data sharing agreements, secondments of personnel or limitations on how results obtained with the data can be distributed. | Recommended | 2 | The CUH Legal Counsel is responsible for managing contracts related to the SDE. |
Download: 20250815_EoE-SDE_SATRE_evaluation.csv ⇓