TRE Data Retention and Deletion Policy: A Practical Guide
A data retention and deletion policy for a Trusted Research Environment (TRE) defines how long each category of data and artifact is kept inside the environment, who decides, and how it is securely destroyed when the period ends. A complete policy covers far more than the source datasets: it must address researcher workspaces, derived datasets, intermediate files, model artifacts, released outputs, audit logs, and backups, each with its own retention period and deletion method. The strongest policies are enforced by the platform automatically rather than by periodic manual clean-ups.
Why retention and deletion matter now
Retention used to be treated as housekeeping. It is now a core part of how regulators, data custodians, and participants judge whether a research environment deserves trust. Under the General Data Protection Regulation (GDPR), Article 5(1)(e) sets the storage limitation principle: personal data should be kept in identifiable form no longer than necessary. Article 89 allows longer storage for research purposes, but only with appropriate safeguards. The European Health Data Space regulation adds its own expectations for secure processing environments that host secondary use of health data.
The May 2026 UK Biobank incident gave the issue practical urgency. Approved researchers were able to move data out of a centralized platform through its normal workflow. Every copy of data that exists in a researcher workspace is a copy that can be misused, forgotten, or exported. A TRE that cannot say exactly which copies exist, and when each will be destroyed, cannot credibly claim to control its data.
What a TRE retention policy must cover
The full inventory of data categories
Most retention failures come from categories that nobody listed. A TRE policy should name every class of material the environment holds and set a rule for each.
| Data category | Typical retention trigger | Deletion method | Owner of the decision |
|---|---|---|---|
| Source datasets | Custodian’s own retention schedule and legal obligations | Custodian-controlled destruction under its records policy | Data custodian |
| Project extracts and working copies | End of the approved project or data access agreement | Automated deletion at project closure, with verification | TRE operator, as agreed with the custodian |
| Derived datasets and intermediate files | Project closure, unless approved for retention for reproducibility | Deletion with the project workspace, or archiving under a new approval | Principal investigator and data access committee |
| Trained models and analysis artifacts | Project closure or approved release | Deletion, or release through output checking if approved | Data access committee |
| Released outputs | Governed by publication and reproducibility needs | Held outside the TRE once checked and released | Principal investigator |
| Audit logs | Legal and accreditation requirements, usually longer than project data | Secure deletion after the retention period, with integrity preserved until then | TRE operator and information governance lead |
| Backups and snapshots | Backup rotation cycle | Expiry through rotation, or cryptographic erasure | TRE operator |
Retention periods and their justification
Each period needs a documented reason. For research data, reasons include the length of the approved project, requirements to support reproducibility or regulatory inspection, contractual terms in data access agreements, and legal obligations. In the United States, the HIPAA Security Rule requires covered entities to retain required documentation, such as policies and assessments, for six years (45 CFR 164.316(b)(2)). Clinical trial sponsors follow retention requirements for essential records under Good Clinical Practice. Where laws differ between jurisdictions, the policy should follow the stricter rule and say so.
Deletion that can be verified
Deletion is only meaningful if it can be demonstrated. NIST Special Publication 800-88, Guidelines for Media Sanitization, describes three levels: clear, purge, and destroy. In cloud environments, where physical media are not under the operator’s control, cryptographic erasure is a common approach: data is encrypted with project-specific keys, and destroying the keys renders every copy unreadable, including copies in backups. The policy should state the method used for each category and how deletion is recorded.
Participant rights and research exemptions
GDPR Article 17 gives individuals a right to erasure, but Article 17(3)(d) limits it where erasure would render impossible or seriously impair the achievement of research objectives, provided Article 89 safeguards are in place. That exemption does not remove the need to plan. Many biobanks and cohorts offer participants options to withdraw from future research use, and a TRE must be able to act on those withdrawals.
In practice, that means the environment needs to know which projects hold which participants’ data, and how a withdrawal propagates. Our guide to the GDPR Article 89 research exemption explains the safeguards, and the article on anonymization vs pseudonymization under GDPR covers why pseudonymized research data usually still falls within scope.
The federated TRE angle
Retention is hardest where copies multiply. In a centralized TRE, data is first transferred from each custodian into the platform, then extracted into project workspaces, then transformed into derived tables, and sometimes downloaded by mistake or by design. Each step creates another copy with another retention clock. Deleting a dataset properly means finding every one of them.
A federated TRE removes most of those copies by design. Analysis runs where the data is held, under the custodian’s own infrastructure and retention policy, and only checked aggregate outputs leave. Because data never leaves the source, there is no central replica of the source data to track and destroy, and no cross-border copy whose deletion has to be proven to a foreign regulator. The retention policy becomes simpler: the custodian governs the source data as it always has, and the TRE governs a much smaller set of project artifacts and outputs.
Lifebit’s federated TRE supports that model with project-scoped workspaces that close when the approved project ends, an automated airlock that records every released output, and audit logging that shows what was run and what left. Those records are exactly what an auditor asks for when testing whether a retention policy is applied in practice. For the wider operating model, see our guide on how to implement a Trusted Research Environment.
A practical framework for writing the policy
- Build the inventory. List every data category in the environment, including logs, backups, container images that may embed data, and temporary storage. If a category is not on the list, it will not be deleted.
- Assign an owner. For each category, name who decides retention and who executes deletion. Custodians, operators, investigators, and access committees each own different categories.
- Set periods with reasons. Tie each period to a project approval, contract, legal rule, or reproducibility requirement. Record the source of the requirement.
- Automate the triggers. Link deletion to events the platform already knows about, such as project end dates and access agreement expiry, so clean-up does not depend on someone remembering.
- Choose deletion methods. Specify deletion, purge, or cryptographic erasure for each category, following recognized guidance such as NIST SP 800-88.
- Prove it. Generate a deletion record for each action, retained with the audit logs, and review a sample regularly.
- Handle exceptions formally. Legal holds, regulatory inspections, and reproducibility requests should extend retention only through a documented approval with its own end date.
Real-world practice
The Five Safes framework, used widely by TREs in the UK and elsewhere, frames retention as part of safe settings and safe data: the environment controls where data can go and for how long. Accreditation schemes and information governance standards typically require documented retention schedules and evidence of secure disposal. Public research resources such as UK Biobank publish participant withdrawal options, which shows that withdrawal handling is an expected part of operating a large research resource.
Lifebit works with custodians such as Genomics England and CanPath on federated infrastructure in which the custodian keeps control of the source data. That arrangement lets each custodian apply its existing retention and withdrawal processes without having to chase copies held elsewhere.
Common pitfalls
Forgetting backups
Deleting a workspace does not delete its backups. Either align backup rotation with retention periods or use cryptographic erasure so backups become unreadable when keys are destroyed.
Leaving closed projects open
Projects that finish without a formal closure keep their workspaces indefinitely. Tie closure to the access agreement end date and enforce it automatically.
Deleting audit logs too early
Logs often need to outlive the data they describe, because they are the evidence that the data was handled properly. Give them their own retention period.
Letting exceptions become permanent
Legal holds and reproducibility extensions are legitimate, but they tend to outlive the reason for them. An extension granted for a journal’s peer review can quietly become indefinite storage once the paper is published and the team moves on. Give every exception an end date, an owner, and a review reminder, and report open exceptions to the information governance lead on a regular schedule. If an extension is renewed repeatedly, that is a signal the retention period itself may be wrong and should be revisited through the normal policy process.
Treating outputs as risk-free
Released outputs are outside the TRE’s control once they leave. That is why output checking before release matters as much as deletion afterwards.
What to do next
Start with the inventory. Walk through one completed project in your environment and list every place its data or derivatives still exist, including backups and logs. The gaps you find will shape the policy more usefully than any template. If the list is long, consider how a federated design would shorten it, and read Lifebit’s overview of the federated Trusted Research Environment.
Frequently asked questions
How long should a TRE keep research data?
There is no single period. Retention should follow the approved project duration, contractual terms in data access agreements, legal requirements, and any documented reproducibility needs. Each category of data should have its own justified period.
Does GDPR allow research data to be kept indefinitely?
No. Article 89 allows longer storage for research purposes, but only with appropriate safeguards and only for as long as the data is needed. The storage limitation principle in Article 5(1)(e) still applies.
Do participants have a right to have their data deleted from research?
GDPR Article 17 provides a right to erasure, but Article 17(3)(d) limits it where erasure would seriously impair research objectives and safeguards are in place. Many research resources still offer withdrawal options, so TREs need a process to act on them.
How should data be deleted in a cloud-based TRE?
Common approaches include logical deletion with verification and cryptographic erasure, where project-specific encryption keys are destroyed so every copy, including backups, becomes unreadable. NIST SP 800-88 provides recognized guidance on sanitization methods.
How does a federated TRE simplify retention?
Because analysis runs where the data is held and only checked aggregates leave, there is no central copy of the source data to track or delete. The custodian applies its existing retention policy, and the TRE manages a smaller set of project artifacts.
Should audit logs be deleted with project data?
Usually not. Audit logs are the evidence that data was handled correctly, so they typically need a longer retention period than the project data itself, set by legal and accreditation requirements.