UK Biobank locked 20,000 researchers out of 30 petabytes of genomic data for months after someone listed 500,000 volunteers' health records for sale on Alibaba. The charity is now piloting manual output checking before any researcher can download a file.
This isn't a new control. It's a last resort after years of preventable mistakes.
Why These Mistakes Keep Happening
Research platforms face a dilemma. Researchers need flexible access to run experiments, while compliance teams need strict output controls. Most organizations prioritize researcher convenience, only tightening security after a breach.
The pattern repeats because teams treat output checking as a technical issue (what scanning tool should we buy?) rather than a governance issue (who reviews what, when, and under what authority?). Automated scans catch obvious errors but miss context-dependent exposure, while manual reviews can bottleneck work if no clear approval criteria exist.
Mistake 1: Treating Code Repositories as Internal Infrastructure
Why it happens: Your researchers upload analysis code to GitHub or GitLab repos they consider "private" or "internal." These repos feel like working directories, not publication channels. No one thinks of them as data egress points.
The consequence: De-identified participant data gets embedded in code samples, configuration files, or test datasets. UK Biobank runs daily automated scans to catch this error but still finds researchers exposing participant data in their repos despite repeated warnings. Once code is pushed to a public or inadequately secured repo, you've lost control of the data.
The fix: Classify all code repositories as controlled egress channels in your data flow maps. Require the same output review for code commits that you require for file downloads. Implement pre-commit hooks that block pushes containing patterns matching your data labeling scheme (participant IDs, genomic markers, clinical codes). Train researchers to use synthetic data for testing and examples, never production data extracts.
Mistake 2: Relying Entirely on Automated Scanning Without Review Authority
Why it happens: You deploy a scanning tool that flags sensitive data patterns in outputs. The tool generates alerts, but no one has clear authority to reject a download or escalate a borderline case. Researchers treat scan results as suggestions, not gates.
The consequence: Automated scans catch obvious mistakes (a CSV file named "participant_data.csv") but miss contextual exposure (aggregate statistics that become re-identifiable when combined with public datasets). Without a defined reviewer who can say "no," researchers work around scan results or ignore them entirely.
The fix: Establish a designated output review function with documented authority to reject downloads and require remediation. UK Biobank's manual checking system assigns human reviewers to inspect files before release. Define approval criteria in writing: what aggregate threshold prevents re-identification, what metadata can accompany results, what documentation must support each download request. Automated scans feed the review queue; they don't replace the reviewer's judgment.
Mistake 3: Granting Permanent Local Storage Rights
Why it happens: Researchers download datasets to their local machines for "faster" analysis or because they're accustomed to working offline. Your platform allows this because restricting downloads feels like restricting research productivity.
The consequence: You lose visibility and control the moment data leaves your platform. Researchers store datasets on unencrypted laptops, share files via email, or retain data long after their project concludes. UK Biobank is now moving toward a model where researchers store no data locally, working only within hosted environments.
The fix: Restrict all analysis to platform-hosted environments with no local download capability. Provide sufficient compute resources and interactive tools within the controlled environment so researchers don't need local copies. When downloads are unavoidable (final publication-ready results), require output review and apply Time-to-Live limits. After 90 days, the downloaded file should auto-delete or require re-approval to retain.
Mistake 4: Allowing Unrestricted Data Sharing Between Researchers
Why it happens: Collaboration is essential to research. Your platform lets researchers build shared apps, grant access to colleagues, or transfer datasets between projects without friction. Restricting these workflows feels like impeding legitimate science.
The consequence: Data access sprawls beyond your approved researcher list. A researcher shares a tool with an external colleague who hasn't signed your Material Transfer Agreement, hasn't completed training, and isn't subject to your sanctions. UK Biobank restricted researchers from sharing tools externally until its manual checking system is operational.
The fix: Require approval for every data share, even between internal researchers. Implement role-based access that grants data access only after verifying current training status, signed agreements, and active project affiliation. Log every share event with recipient identity and justification. External shares require the same output review as downloads, because a shared tool is an egress channel.
Mistake 5: Failing to Enforce Sanctions for Repeated Violations
Why it happens: A researcher accidentally exposes data in a code repo. You send a warning email. They acknowledge the mistake. You consider the matter closed. When it happens again, you send another warning, because revoking access feels disproportionate and researchers are valuable collaborators.
The consequence: Repeat offenders continue making the same mistakes because there's no meaningful penalty. UK Biobank is now applying sanctions against researchers who repeatedly expose participant data: forced migration to the controlled platform, deletion of all downloaded data, mandatory retraining, and access suspension until compliance is verified.
The fix: Document a progressive discipline policy tied to your Material Transfer Agreement. First violation: mandatory retraining and audit of all researcher-held data. Second violation: access suspension until remediation is complete and verified. Third violation: permanent revocation and notification to the researcher's institution. Apply these sanctions consistently, regardless of the researcher's seniority or project importance. Sanctions deter future violations more effectively than scanning tools.
Prevention Checklist
- Classify all code repositories and shared tools as controlled egress channels requiring output review
- Designate reviewers with documented authority to reject downloads and require remediation
- Define written approval criteria for output review (aggregate thresholds, metadata rules, documentation requirements)
- Restrict analysis to platform-hosted environments; eliminate routine local downloads
- Implement pre-commit hooks that block code pushes containing data patterns matching your labeling scheme
- Require approval for every data share, internal or external, with logged justification
- Apply Time-to-Live limits to any approved downloads with auto-deletion after the retention period
- Document and enforce progressive sanctions for Material Transfer Agreement violations
- Verify deletion of researcher-held data before restoring platform access after a violation
- Audit researcher training status and agreement signatures before granting each new data access request
The UK Biobank breach exposed 500,000 volunteers' data because output controls failed before data left the platform. Manual checking and automated scans are necessary, but they're effective only when backed by clear authority, enforced sanctions, and a governance model that treats every egress channel as a compliance boundary.
