There is no a single standard airlock. Sensitive data, whether patient records or financial information, requires control governing the sharing of that data. These controls must conform with the common common law concept of confidentiality, data protection laws (primarily UK GDPR and the Data Protection Act 2018) and variance across organisational governance. Specifically the variant approvals, risk assessments and access processes operated across NHS England, NHS trusts, universities and other data custodians. The common term for the mechanism that enforces safe output is “airlock.” Like most software metaphors there’s no actual agreement on the chamber between two pressure zones.
No ISO standard exists. No RFC exists. No universally accepted technical specification exists. People use the term loosely across implementations that share little beyond the name. Some are file-based export gates with human reviewers. Others are query-level policy engines with automated checks. The DARE UK SATRE project (Standardised Architecture for Trusted Research Environments) comes closest to a formal spec, with 29 capabilities and 160 assessment statements. But it defines a benchmarking framework, not a prescriptive blueprint. Two organisations can both satisfy SATRE and have radically different airlock implementations.
This article sets out the core requirements that any credible airlock should meet, compares how the leading TREs implement them, and explores how to build airlock-like controls on Databricks and Snowflake. It also provides some code on how to implement airlocks in both Databricks and Snowflake using their out of the box features: https://github.com/charlesgibbons/airlock
Five Safe System Addict
The intellectual foundation for airlocks is the Five Safes framework. Felix Ritchie originally developed it at the UK Office for National Statistics in 2003 to describe the security model for its Virtual Microdata Laboratory. It has since become the dominant framework for designing secure data access across the NHS and UK public sector. The Office for Statistics Regulation, NHS England, and DARE UK all promote it. It remains a set of guiding principles rather than a binding standard.
The five dimensions are Safe People (researchers are vetted, trained, and identifiable), Safe Projects (every analysis has explicit ethics and governance approval), Safe Settings (the data custodian controls the environment), Safe Data (data stays at source, minimised and pseudonymised), and Safe Outputs (only non-disclosive results leave the environment).
The airlock sits at the intersection of Safe Settings and Safe Outputs. It’s the enforcement point where policy meets reality.
Airlock One
Despite the lack of a single standard, existing implementations converge on a common set of capabilities.
1. Inbound Control (Ingress)
Not just outputs need policing. Bringing data, code, and tools into a secure environment carries its own risks. Malware in uploaded files. Data that shouldn’t combine with what’s already inside. Software with unvetted network access.
An airlock should scan all inbound files for viruses and malware. It should validate that the researcher holds correct consents and approvals for the data they want to import. It should review software and libraries for security risks, especially packages that make network calls. And it should log what someone imported and who & why they imported it. Normally the TRE provides a locked down set of tools or provides privacy enhancing technologies (e.g Federated Machine Learning on flower.ai) if external networking (SD-WAN to HPC) is ever required.
2. Outbound Control (Egress)
Every file, query result, or model leaving the secure environment must pass through a controlled gate. This includes any uploads to github repositories or screengrabs. The airlock should hold export requests in a staging area pending review. It should check for direct identifiers (names, NHS numbers, IDs) and indirect re-identification risk (rare combinations of age, condition, location). It should apply statistical disclosure control rules. And it should require explicit approval before release, whether from a human reviewer, an automated system, or both. The key principle is default-deny. Nothing leaves without an affirmative decision. Punishment
3. Statistical Disclosure Control (SDC)
This is where most of the complexity lives. Even aggregate data can expose individuals. If a table shows that 2 people in a specific age range have a specific rare condition in a specific region, someone might identify them from that alone.
Standard SDC rules require small count suppression, meaning the airlock masks any non-zero count below a threshold, typically 5. Totals or other cells must not allow back-calculation of masked values. Ages should appear in 10-year bands, never exact. Variant-level genomic data exports should respect minimum allele frequencies and counts. Individual-level phenotypic descriptions should use only broad, non-identifying terms.
These rules sound simple but enforcing them consistently is surprisingly hard. The difficulty increases across multiple export requests from the same researcher over time, where successive queries might triangulate towards individual-level data.
4. Access Request and Approval
The airlock isn’t just a technical gate. It’s a workflow. A researcher must submit a structured request explaining what they want to export and why. They must describe how the contents relate to their approved project, what disclosure controls they applied, and how they intend to use the exported data. At least one trained output checker reviews the request, and often two independent reviewers assess it. The process must document and audit every approval.
5. Tracking and Audit
The airlock must log every action, inbound or outbound, with an immutable audit trail. Who requested it, why they requested it, what the request contained, who reviewed it, what decision was made against which allowance rule and what actually left the environment.
Cumulative tracking matters too. A single export might look safe in isolation. But a pattern of exports from the same researcher could collectively enable re-identification. The best implementations track disclosure risk across a researcher’s full request history, not just each request individually.
6. Tiered Risk Classification
Not all data carries the same risk. A programming script is very different from a file containing per patient variant calls. Effective airlocks classify data into risk tiers and apply proportionate scrutiny. Low risk outputs like code and logs receive light touch review. Anything containing counts, frequencies, or individual-level information receives rigorous scrutiny. Genomics England uses a 5-tier system, from Tier 1 (participant IDs and raw sequencing data are never exportable) whilst Tier 5 (scripts and technical infrastructure require minimal review).
How the Major TREs Implement Airlocks
OpenSAFELY
The most restrictive model. Researchers never see raw patient data. They develop analysis code against synthetic data, submit it, and the system runs it inside the secure environment against real NHS records. Two trained output checkers independently review the aggregate results before the system releases them. The entire process is open-source and publicly auditable.
OpenSAFELY operates a code-in, results-out pipeline. It’s the closest thing to a zero-trust airlock. The system never trusts the researcher with the data at all. The trade off is that interactive exploration is essentially impossible.
Genomics England
Researchers work inside the Research Environment and can see individual level genomic and clinical data. The Airlock team classifies each export request against the 5-tier risk framework and manually reviews it for disclosure risk.
Key rules: exports must not contain Genomics England IDs. The team rejects non-zero counts below 5 unless the researcher masks them. Ages must appear in bands. Bulk variant exports must meet minimum allele frequency and count thresholds. Machine learning model exports follow their own separate policy because models can memorise training data. The approach is thorough but creates a bottleneck. Requests can take days to clear.
Aridhia
Aridhia recently introduced AIRAlock, combining a deterministic rule engine with an AI advisory layer. When a researcher submits an export request, the system runs automated checks against defined disclosure rules. It approves routine, clearly safe exports quickly. It escalates flagged outputs to human review. The human remains accountable for every decision. The AI advises but doesn’t approve. This is the first serious attempt to partially automate output checking while maintaining the governance trail.
NHS England Secure Data Environment
The national SDE uses Databricks as its analytics platform within a controlled Azure environment. Researchers access data through Databricks notebooks inside the SDE. Outputs pass through a managed egress process. The environment enforces network isolation, and researchers cannot copy data to local machines.
Databricks
Databricks doesn’t ship with an airlock feature, but Unity Catalog and Delta Sharing provide the building blocks.
Unity Catalog delivers centralised governance. It enforces row-level security, column masking, data lineage, and audit logging across all workspaces. Administrators tag columns containing PII, apply dynamic masking policies that resolve at query time based on the user’s role, and track who accessed what and when.
Delta Sharing is an open protocol for cross-organisation data sharing without copying data. The provider publishes specific tables or views. The consumer queries them in place. The provider bakes SDC rules directly into the shared view logic: small count suppression, age banding, aggregation thresholds.
Clean Rooms go further. Multiple parties can run pre-approved analyses (SQL, Python, R, Scala) against combined datasets without seeing each other’s raw data. The clean room environment supports HIPAA compliance and clinical trial teams already use it.
A practical Databricks airlock pattern works as follows. Researchers work in isolated workspaces that Unity Catalog policies govern. Exports route through a managed notebook or job that writes results to a staging table. A Delta Live Tables pipeline runs automated SDC checks against the staging table. Reviewers check flagged results through an approval workflow, which could be as simple as a Databricks SQL dashboard. The system publishes approved results to a Delta Share for the consumer.
The gap: Databricks doesn’t natively enforce a hold-and-review step on query results. Teams would need to build the approval workflow themselves, likely integrating with an external tool like ServiceNow or Jira.
Snowflake
Snowflake’s zero-copy sharing architecture is arguably a more natural fit for the airlock concept. Data physically never moves between accounts.
Secure Data Sharing lets a provider grant read-only access to specific database objects such as tables, secure views, and secure UDFs. The consumer queries the provider’s data in place. No one copies data. No one extracts files.
Secure Views act as the disclosure control layer. The provider defines exactly what the consumer can see, with row filtering, column masking, and aggregation enforced at the view level. The provider encodes SDC rules like count suppression, rounding, and minimum thresholds directly in the view SQL.
Row Access Policies and Column Masking Policies provide dynamic, role-based controls. The same underlying table can present different views to different consumers based on their role.
Data Clean Rooms allow multi-party analysis where the provider controls which queries the consumer can run. Providers can inject calibrated noise, enforce minimum distinct-count thresholds, add timestamp constraints to prevent jitter attacks (where an attacker runs near-identical queries repeatedly to detect small changes in aggregates), and restrict the set of allowed operations.
Reader Accounts provide the most locked-down consumer experience. Read-only access. No data export capability. No DML. The provider funds the compute. This comes close to the TRE model. The researcher can query but cannot extract.
A Snowflake airlock pattern works as follows. The provider exposes data only through secure views with SDC rules baked in. It provisions consumers as reader accounts with no extract capability. Clean room policies restrict queries to pre-approved templates. A stored procedure routes query results into a staging schema. A Snowflake Task runs automated disclosure checks on staged results. The system surfaces approved results to the consumer’s share. Access History and Query History feed into a governance dashboard.
The gap: like Databricks, Snowflake doesn’t natively provide a human-in-the-loop approval gate for individual query results. The staging-table-plus-task pattern approximates this. But teams must build the review workflow themselves.
Databricks & Snowflake Code Comparison
Proof-of-concept implementations of a Trusted Research Environment (TRE) airlock built on two commercial data platforms (Snowflake and Databricks). Each implementation enforces statistical disclosure control, manages export requests through a structured approval workflow, and maintains an immutable audit trail. Each implementation follows the same process as a mechanism for controlling the egress of sensitive data.
SENSITIVE DATA Raw records. Never directly queryable by researchers. |GOVERNED VIEWS SDC rules enforced at query time. Researchers query here. |STAGING Export results held pending review. |CONTROL PLANE Requests, approvals, SDC checks, audit logs. |APPROVED OUTPUTS Reviewed results only. Backs the share layer. |SHARE LAYER Zero-copy consumer access (Snowflake Share / Delta Share).
Snowflake
https://github.com/charlesgibbons/airlock/tree/master/snowflake
Nine SQL scripts covering secure views with SDC, column masking policies, a request/approval workflow via stored procedures, automated SDC check tasks, secure share for approved outputs, and audit dashboard views.
Databricks
https://github.com/charlesgibbons/airlock/tree/master/databricks
Seven SQL scripts plus two Python notebooks covering Unity Catalog column masks and row filters, governed views with SDC, a PySpark request/approval workflow, Delta Sharing for approved outputs, and audit dashboard views.
The SDC approach is slightly different in Databricks with PySpark based output checking.
Signed, Sealed, Delivered
No current platform, whether Databricks, Snowflake, or otherwise, provides a complete out-of-the-box airlock that would satisfy NHS TRE requirements. They provide the primitives: fine-grained access control, dynamic masking, zero-copy sharing, audit logging, and clean room environments.
The same pieces are missing from both platforms. Neither offers a native hold-and-review workflow for output requests. Neither tracks cumulative disclosure risk across multiple queries. Neither enforces standardised SDC rules; teams hand-code them into view logic. Neither integrates with governance processes like ethics approval, project registration, or researcher accreditation.
TRE-specific platforms fill these gaps. OpenSAFELY, Genomics England’s RE, and Aridhia’s DRE have each built the governance layer, review workflows, and SDC enforcement that general-purpose data platforms don’t yet provide.
The opportunity is real though. Snowflake’s zero-copy sharing and Databricks’ Unity Catalog lineage tracking offer technically superior foundations compared to the file-based airlock systems most TREs currently use. The Francis Crick Institute’s LATTICE provides a very interesting governance function. It implements the Safe Havens and data tools that can integrate with the data structure of your choosing.
API Crazy 