When 500,000 health records appear for sale on a Chinese e-commerce platform, you're past the point where contract terms matter. The UK Biobank incident reveals what happens when your data governance framework treats legal agreements as technical controls.
This checklist addresses a specific failure mode: research data sharing arrangements that depend on researcher compliance rather than technical enforcement. If you're managing a biobank, clinical trial dataset, or any research repository where external parties analyze sensitive data, these items apply directly to your program.
Prerequisites
Before using this checklist, confirm:
- You've classified the data according to sensitivity level (identifiable vs. de-identified vs. anonymized).
- You have a complete inventory of which external parties currently hold copies.
- You know whether your current sharing model allows data download or requires cloud-based analysis.
- You've documented your legal basis for processing under GDPR Article 6 and, if applicable, Article 9.
Technical Access Controls
1. Disable raw data export from analysis environments
Your researchers should analyze data inside a controlled environment with no download function. UK Biobank required researchers to sign agreements not to download data but implemented no technical block on export.
What good looks like: A cloud-based research platform where compute happens server-side and only aggregated results (summary statistics, model outputs) can be exported. Any attempt to copy raw participant records triggers an automatic block and audit log entry.
2. Implement automated egress filtering
Even if you disable direct downloads, researchers can still exfiltrate data through screenshots, API calls, or embedding records in analysis outputs.
What good looks like: An "airlock" system that scans all outbound files for patterns matching raw data formats (CSV columns with participant IDs, genome sequences, diagnostic codes). Files containing potential raw data get quarantined for manual review before release. UK Biobank announced this measure post-breach; it should have been in place from day one.
3. Enforce session recording for high-risk datasets
When researchers access identifiable or re-identifiable data, you need a complete audit trail.
What good looks like: Every analysis session is recorded with timestamped logs of queries executed, files accessed, and results generated. Logs are immutable and retained per your Records Disposition Schedule. You can reconstruct exactly what a researcher did during any session.
4. Deploy data loss prevention on researcher endpoints
If researchers access data through desktop clients or download analysis tools, their local machines become exfiltration vectors.
What good looks like: DLP agents installed on approved researcher devices that block file transfers to unauthorized cloud storage, removable media, or email. Attempts trigger alerts to your security team with researcher identity and attempted destination.
Access Governance
5. Verify institutional data protection agreements before granting access
UK Biobank revoked access from three research institutions identified as the source of the leaked data. That tells you the institutions themselves had inadequate controls.
What good looks like: Before approving any access request, you review the applying institution's data protection policies, confirm they have Technical and Organisational Measures appropriate to the data sensitivity, and verify they'll enforce consequences for researcher violations. Document this review in your access approval record.
6. Implement time-bound access with mandatory re-certification
Perpetual access creates perpetual risk. Researchers who completed their analysis two years ago shouldn't still have credentials.
What good looks like: Access grants expire after a defined period (6-12 months for most research projects). Renewal requires the researcher to certify they still need the data and haven't violated terms. Expired credentials are automatically deprovisioned.
7. Enforce multi-party approval for bulk data access
No single administrator should be able to grant access to your entire dataset.
What good looks like: Requests to access more than a threshold number of records (e.g., 10,000 participants) require approval from both a data custodian and a privacy officer. The approval includes a documented justification for why the research question requires that sample size.
De-identification Controls
8. Assess re-identification risk before calling data "de-identified"
The UK Biobank data was described as de-identified because it lacked names and addresses. But a Guardian reporter re-identified a participant from diagnosis records in a leaked dataset.
What good looks like: You've conducted a formal re-identification risk assessment per ISO/IEC 29134 methodology, considering quasi-identifiers (rare diagnoses, geographic indicators, temporal patterns) and available external datasets. Document the assessment and the risk level. If re-identification risk is non-negligible, apply additional controls or treat the data as identifiable.
9. Remove or generalize high-risk quasi-identifiers
Rare diagnoses, precise timestamps, and fine-grained geographic data enable re-identification even without names.
What good looks like: Before sharing, you've applied k-anonymity or differential privacy techniques to ensure no individual can be singled out. For diagnosis codes, you generalize rare conditions to broader categories. For dates, you use month/year instead of exact dates. For locations, you use regions instead of postcodes.
Breach Response Readiness
10. Maintain a current inventory of data locations
UK Biobank suspended all access to investigate. That response only works if you know where your data lives.
What good looks like: A Data Labeling system that tracks every authorized copy of your dataset: which institution holds it, which researchers have credentials, when access was granted, and what version of the data they received. You can generate this list in under an hour.
11. Pre-establish supervisory authority reporting procedures
UK Biobank referred itself to the Information Commissioner's Office. You should know your reporting obligations before an incident.
What good looks like: A documented procedure that specifies when you must make a Notification to Supervisory Authority (within 72 hours of becoming aware of a breach under GDPR Article 33), who internally has authority to make that decision, and what information you'll include. Template language prepared in advance.
12. Test your emergency access suspension capability
UK Biobank's ability to suspend all access prevented further exposure. Can you do the same?
What good looks like: Quarterly tests where you execute a simulated suspension: revoke all researcher credentials, disable platform access, and verify no one can reach the data. Time how long the process takes. Your target: under 4 hours from decision to complete lockdown.
Common Mistakes
Treating contract terms as security controls. Legal agreements establish liability, not prevention. If a researcher can download data, a signature promising they won't is worthless.
Assuming de-identification eliminates privacy risk. Re-identification attacks succeed against supposedly anonymized datasets regularly. De-identification reduces risk; it doesn't eliminate it.
Granting access without institutional vetting. Individual researchers work within institutional contexts. If the university has weak data protection practices, the researcher's good intentions won't matter.
Failing to test suspension procedures. You'll discover your access revocation process is broken when you need it most. Test it now.
Next Steps
If you're operating a research data sharing program:
- Audit your current technical controls against items 1-4. If researchers can export raw data, that's your priority fix.
- Review access grants from the past 24 months. Identify any that should have expired and revoke them.
- Conduct a re-identification risk assessment on your "de-identified" datasets. If you can't demonstrate low risk, reclassify them as identifiable and apply Article 9 safeguards.
The UK Biobank incident demonstrates that even well-funded, scientifically valuable programs can fail at basic data governance. Your contract with researchers should specify consequences for violations. Your technical architecture should make violations impossible.
