What Is the Five Safes Framework in Research Data?
Quick answer. The Five Safes framework is the canonical model for governing research access to sensitive data, comprising Safe People, Safe Projects, Safe Settings, Safe Data and Safe Outputs. Developed by the UK Office for National Statistics (ONS), it is now the de facto standard adopted by Trusted Research Environments (TREs) and statistical agencies worldwide.
The Five Safes framework is the canonical model for governing research access to sensitive data. Developed by the UK Office for National Statistics (ONS) in the mid-2000s, it decomposes the question “is this access safe?” into five orthogonal dimensions: Safe People, Safe Projects, Safe Settings, Safe Data and Safe Outputs. Every contemporary Trusted Research Environment (TRE) — and the federated TRE architecture that has emerged in the last five years — maps its controls back to those five axes.
Why the Five Safes matter now
The framework has moved from statistical-agency obscurity to operational bedrock because the regulatory perimeter around sensitive health and genomic data has tightened sharply. The European Health Data Space (EHDS) Regulation requires Member States to make health data available for secondary use through “secure processing environments” — language that maps almost verbatim onto Safe Settings. The UK Data (Use and Access) Act, US 21st Century Cures Act and Australian Data Availability and Transparency Act all assume an equivalent governance lattice.
The May 2026 UK Biobank incident — in which approved researchers exfiltrated derived datasets through a centralised software-as-a-service (SaaS) TRE’s normal export workflow — sharpened the conversation. Post-incident reviews did not conclude that the Five Safes were wrong. They concluded that Safe Outputs, the historically weakest leg, must be automated and architecturally enforced rather than left to manual statistical-disclosure review.
The five Safes, one by one
Safe People
Safe People asks whether the researcher is appropriately trained, accredited and accountable. In practice this means identity verification, institutional affiliation checks, completion of an accredited researcher scheme (the ONS Approved Researcher Scheme, the HDR UK Safe Researcher Training, or equivalent), and a signed end-user agreement exposing the researcher to civil and criminal sanctions for misuse. Safe People is the human-trust layer; everything downstream assumes the named individual is at the keyboard.
Safe Projects
Safe Projects asks whether the proposed research is lawful, ethical and in the public interest. A Data Access Committee (DAC) reviews the protocol, the lawful basis under the General Data Protection Regulation (GDPR) or equivalent, the patient and public involvement evidence, and the proportionality of the requested data to the scientific question. Projects fail this leg when they ask for more identifiable data than the hypothesis justifies.
Safe Settings
Safe Settings is the technical environment in which the analysis runs. Historically a physical “safe room”; in the modern TRE, a remote-desktop or notebook environment with hardened egress controls, full session logging, encrypted storage and an immutable audit trail. The federated TRE architecture extends Safe Settings outward: the secure environment is instantiated at the custodian’s premises, so the data never leaves the source.
Safe Data
Safe Data asks how much identifying detail the analyst actually needs to see. Statistical disclosure control techniques — pseudonymisation, k-anonymity, suppression of small cells, perturbation of geographic granularity, differential privacy noise — are applied before the researcher ever touches the dataset. A well-run TRE will offer the same underlying cohort at multiple data-minimisation tiers, and the DAC will route a project to the least-identifiable tier that still answers the question.
Safe Outputs
Safe Outputs governs what leaves the environment. Tables, regression coefficients, plots and trained model weights all carry residual disclosure risk — an aggregate cell of “1” identifies a person, and a model overfit to rare cases can memorise training records. Output checking has traditionally been a manual review against rules such as the ONS Safe Outputs handbook. The May 2026 incident made the case that manual review at scale is the framework’s weakest link.
The ONS origin and global adoption
The Five Safes was articulated by Felix Ritchie and colleagues at the UK Office for National Statistics around 2003 as internal vocabulary for the Virtual Microdata Laboratory, and published openly in 2009. It was deliberately framework-agnostic — it described what a safe access regime must address, not how any particular technology should implement it. That portability is why it travelled.
The Five Safes is now embedded in the operating manuals of Health Data Research UK, NHS England’s Secure Data Environment policy, the Australian Bureau of Statistics DataLab, Statistics Canada’s Research Data Centres, the European Statistical System and the OECD’s recommendation on health data governance. Public reference TREs including the UK Biobank Research Analysis Platform, the Genomics England Research Environment, the All of Us Researcher Workbench and Singapore PRECISE all cite the Five Safes in their governance documentation. It has become the lingua franca of research data governance.
The “sixth Safe” — automated airlock at the federation boundary
The Five Safes was designed for an era in which data moved to compute. A central custodian copied a de-identified extract into a hosted environment, the researcher logged in, and outputs were manually reviewed on the way out. Federated TREs invert that flow: compute moves to the data, and the data stays at source. That inversion creates a sharp architectural boundary — the federation interface — that did not exist in the original framework.
Several federated TRE operators now describe an explicit “sixth Safe” — sometimes Safe Federation or Safe Egress — at this boundary. It is implemented as an automated airlock: every artefact attempting to cross from a node back to the federated query layer (a count, a coefficient, a Kaplan-Meier curve, a model weight vector) is intercepted, scanned against statistical disclosure control rules, optionally noise-injected for differential privacy, and either released, quarantined or rejected. The check is policy-as-code, runs on every output without exception, and produces an immutable cryptographic log. It does not replace any of the original five Safes; it operationalises Safe Outputs at machine speed.
The Five Safes mapped to control mechanisms
| Safe | Governs | Primary control mechanism |
|---|---|---|
| Safe People | Is the researcher trustworthy and accountable? | Accredited researcher scheme, identity verification, signed end-user agreement, role-based access control |
| Safe Projects | Is the research lawful, ethical and proportionate? | Data Access Committee review, Research Ethics Committee approval, GDPR lawful basis documentation, public benefit test |
| Safe Settings | Is the analysis environment secure? | Trusted Research Environment with egress controls, session logging, encrypted storage, ISO 27001 / SOC 2 / FedRAMP attestation |
| Safe Data | Is the data minimised to what the project needs? | Pseudonymisation, k-anonymity, suppression of small cells, tiered data minimisation, differential privacy at ingest |
| Safe Outputs | Is everything that leaves the environment non-disclosive? | Statistical disclosure control review, output checking against ONS Safe Outputs handbook, automated airlock policy-as-code |
| Safe Federation (proposed sixth) | Is every cross-node artefact safe to release? | Automated airlock at the federation boundary, cryptographic audit log, machine-enforced statistical disclosure control on every output |
How federated TREs operationalise the Five Safes
In a centralised SaaS TRE, the custodian ships a de-identified copy of the cohort into a hosted environment and trusts the operator’s controls. Safe Settings is a tenancy claim. Safe Outputs is a manual review queue. The boundary between custodian and operator is blurry — the seam exposed in May 2026.
A federated Trusted Research Environment changes the topology. Each data custodian — a national biobank, a hospital network, a ministry of health, a pharma R&D site — runs a node inside its own perimeter. The federated TRE orchestrates queries that travel to the nodes, execute against local data, and return only the aggregated, airlock-checked result. Safe Settings is enforced at the custodian’s own infrastructure under the custodian’s own attestation. Safe Outputs is enforced by the automated airlock on every output. The Five Safes are not abandoned — they are tightened, because each leg now has an architectural rather than a procedural answer.
Practical adoption checklist
Evaluators auditing a TRE against the Five Safes should ask, for each leg: what is the control, who attests, and is the log immutable. For Safe People, require evidence of accredited researcher scheme integration. For Safe Projects, require a documented DAC workflow. For Safe Settings, request ISO 27001, SOC 2 Type II or FedRAMP Moderate attestation tied to the environment. For Safe Data, ask which disclosure control techniques apply at which tier. For Safe Outputs, ask whether checking is manual or policy-as-code. For the federation boundary, ask whether the airlock is enforced on every output and whether the log is cryptographically signed.
Frequently asked questions
Who invented the Five Safes framework?
The Five Safes was developed by Felix Ritchie and colleagues at the UK Office for National Statistics in the early 2000s as a vocabulary for the Virtual Microdata Laboratory, and published openly in 2009. It has since been adopted by statistical agencies, biobanks and Trusted Research Environments across the UK, EU, US, Canada, Australia and Singapore.
Is the Five Safes a legal requirement?
Not directly, but it is referenced in operational guidance under the UK Data Protection Act 2018, the European Health Data Space Regulation, NHS England’s Secure Data Environment policy and the OECD recommendation on health data governance. In practice, demonstrating Five Safes alignment is the usual route to satisfying the security-and-governance clauses in those instruments.
What is the difference between Safe Data and Safe Outputs?
Safe Data is applied before the researcher sees anything — pseudonymisation, suppression of small cells, tiering by identifiability. Safe Outputs is applied to whatever the researcher tries to take out — tables, plots, model weights — and asks whether any of those artefacts could re-identify an individual. Safe Data hardens the input; Safe Outputs hardens the export.
Why do some federated TREs add a sixth Safe?
The original five Safes assumed a single secure environment. Federated TREs run queries across multiple custodian nodes, which creates a new architectural boundary — the federation interface — where outputs are aggregated and released. Calling that an explicit sixth Safe (sometimes Safe Federation or Safe Egress) makes the automated airlock at that boundary a first-class governance object rather than an implementation detail of Safe Outputs.
How does the Five Safes relate to GDPR?
GDPR requires lawful basis, data minimisation, purpose limitation, integrity and confidentiality, and accountability. The Five Safes provides an operational mapping: Safe Projects evidences lawful basis and purpose limitation; Safe Data evidences minimisation; Safe Settings and Safe Outputs evidence integrity and confidentiality; Safe People and the audit trail evidence accountability.
Can a centralised SaaS TRE satisfy the Five Safes?
Yes, in principle, and many do. The May 2026 UK Biobank incident did not prove that centralised TREs cannot satisfy the framework — it proved that Safe Outputs is hard to enforce at human review speed for large cohorts. Federated TRE architectures address the same problem by making the airlock automated and architectural.
Does the Five Safes apply outside health data?
Yes. It originated in official statistics and is used by statistical agencies for census microdata, tax records and labour market data. Its adoption in health, genomics and clinical trial data is a relatively recent extension. The vocabulary is domain-neutral — any setting making sensitive individual-level data available for secondary research benefits from the same five-axis decomposition.