What Is a Data Access Committee? How Modern DACs Work

A Data Access Committee (DAC) is the governance body that reviews and decides applications from researchers who want to use a sensitive dataset — typically a biobank, national genomics programme, disease registry, or health-system cohort. A DAC assesses who is applying, what they propose to do, and whether the request fits the consent, law, and policies under which the data was collected. In modern infrastructure, the DAC’s decision no longer releases a copy of the data; it grants entry to a Federated Trusted Research Environment (TRE) where the approved analysis runs under continuous technical enforcement.

Why DACs matter now

Every serious data custodian runs one. The European Genome-phenome Archive (EGA) lists hundreds of DACs governing its controlled-access datasets; the database of Genotypes and Phenotypes (dbGaP), the United States’ public repository for genomic studies, routes every application through data access committees; UK Biobank operates a structured access-management process for its half-million-participant cohort; and Genomics England’s Access Review Committee governs entry to the National Genomic Research Library. The committee model is universal because the legal and ethical position is universal: participants consented to research use under conditions, and somebody accountable must check that each proposed use honours them.

What has changed is the weight the decision carries. When a DAC approval meant posting an encrypted hard drive or opening a download link, the committee’s judgement was the final control — after transfer, enforcement was contractual hope. The May 2026 UK Biobank incident made the consequence concrete: approved researchers exported participant-level data through a centralised platform’s normal, policy-compliant workflow. No committee misjudged the applicants; the architecture simply had nothing behind the committee. Meanwhile the European Health Data Space (EHDS) has effectively legislated the committee-plus-environment model for the EU: Health Data Access Bodies assess applications, issue data permits, and provide access only inside secure processing environments from which personal data cannot be downloaded. Regulation is converging on what mature programmes already do.

What a DAC actually reviews

The classical checklist

DAC review maps closely onto the Five Safes framework developed at the UK Office for National Statistics — the same framework that underpins TRE design, described in our guide to the Five Safes. The committee evaluates Safe People (are the applicants bona fide researchers with appropriate training and institutional backing?), Safe Projects (is the proposed use scientifically sound, in the public interest, and within the scope of consent and law?), and the terms under which the remaining safes — Settings, Data, and Outputs — will be enforced. Most committees also check funding and conflicts of interest, data-sharing intentions, and whether the requested data is proportionate to the question: a request for full genomes to answer a question that phenotype data can answer should come back trimmed.

The machinery: agreements, ontologies, and identity

Behind the judgement sits paperwork that modern standards are steadily structuring. Data use conditions — “disease-specific research only”, “no commercial use”, “ethics approval required” — are increasingly encoded in the Global Alliance for Genomics and Health (GA4GH) Data Use Ontology (DUO), which lets a machine pre-match an application’s stated purpose against a dataset’s permitted uses before a human ever reads it. GA4GH Passports do the same for researcher identity, carrying verified claims about affiliation and recognised-researcher status across institutions. Neither replaces the committee; both strip out the correspondence overhead that makes DAC review slow — chasing institutional signatures, verifying identities, and rejecting applications that were never eligible.

How modern DACs work inside a Federated Trusted Research Environment

The structural shift is from approving a transfer to approving an entry. In a Federated Trusted Research Environment, the dataset stays with its custodian — the data never leaves the source — and an approved researcher receives a governed workspace scoped to exactly the data and tools the committee authorised. That single change transforms the committee’s job in four ways.

First, the decision becomes enforceable. Approval provisions an environment whose permissions mirror the permit; revocation de-provisions it. There is no copy in the wild to regret. Second, the decision becomes observable. Every query, notebook, and export attempt inside a Trusted Research Environment is logged, so the committee — and the auditor, and ultimately the participant panel — can see that use matched approval, closing the loop that pure release models leave open. Third, the risk profile of the decision itself drops. A committee releasing files must weigh worst-case downstream misuse of the entire dataset; a committee granting environment access knows that outputs will pass an automated airlock that checks every result leaving the environment for disclosure risk. Lower-stakes decisions can safely be faster decisions. Fourth, federation extends the committee’s reach across borders: in a network of Federated Trusted Research Environments, each custodian’s DAC approves use of its own data under its own law, and an approved multi-site analysis runs at every source without any committee having to authorise a transfer abroad — which for many cross-border studies is the difference between possible and not.

Tiered access: not every request needs the full committee

Mature programmes also recognise that access is not binary, and a well-designed tier structure is what keeps a Data Access Committee’s workload proportionate to risk. A common three-tier pattern: an open tier exposes dataset metadata, documentation, and aggregate summary statistics to anyone, so researchers can establish whether the data can answer their question before applying; a registered tier gives authenticated, terms-accepting researchers access to richer aggregates and cohort-discovery queries — protected by disclosure controls such as minimum count thresholds — without individual DAC review; and a controlled tier, gated by full committee review, grants analysis access to record-level data inside the Federated Trusted Research Environment. The effect on committee throughput is substantial, because a large share of would-be applications resolve at the first two tiers — either the dataset cannot answer the question, or an aggregate answer suffices. The committee’s scarce judgement is then spent only where record-level access is genuinely required, and the audit position improves too: each tier has its own defined controls, rather than one committee decision standing behind every kind of access from a headline count to a genome.

Traditional DAC versus modern DAC

Real-world example: national programmes

Genomics England illustrates the modern pattern end to end. Access to the National Genomic Research Library is decided by its Access Review Committee, which includes participant representatives — governance with the people the data describes at the table. Approved researchers do not receive genomes; they enter a research environment where analysis runs in place, and Genomics England works with Lifebit to extend that model into federated analysis across distributed datasets. Singapore’s Ministry of Health applies committee-governed, environment-based access to precision-medicine data across its health clusters, and the Canadian Partnership for Tomorrow’s Health (CanPath) coordinates access to a multi-province cohort on the same principle. Across all three, the committee remains the human heart of governance — the Federated Trusted Research Environment is what makes its decisions stick.

Common pitfalls

Programmes modernising a DAC tend to hit the same four problems. Bottleneck committees: when one panel hand-reviews every application from scratch, queues stretch to months; the fix is triage — machine-checkable eligibility first, human judgement reserved for merits and edge cases. Approval theatre: a rigorous committee in front of a release-based architecture is a strong lock on a door standing in an open field; review quality cannot compensate for absent enforcement. Scope drift: without audit visibility, an approval for one project quietly becomes a licence for the applicant’s next three; environment logging plus periodic re-attestation keeps use aligned with approval. And forgetting the participant: committees that include participant or public members, and publish plain-language registers of approved projects, sustain the social licence that every downstream control depends on.

What to do next

If you operate or advise a DAC, three assessments are worth running this quarter. Map your review criteria to the Five Safes and identify which safes have technical enforcement behind them versus paper alone. Measure your application pipeline — time to decision, proportion rejected for eligibility rather than merit — to size the gain from DUO-coded pre-screening. And evaluate what approval physically grants: if the answer is still a file transfer, the highest-value modernisation available is putting a Federated Trusted Research Environment behind the committee, so that every future approval is scoped, observable, and revocable by construction.

Frequently asked questions

What is a Data Access Committee?

A Data Access Committee (DAC) is the body that reviews researchers’ applications to use a controlled-access dataset and decides whether the proposed use fits the consent, law, and policies governing the data — typically assessing the applicants, the project, and the safeguards.

Who sits on a DAC?

Composition varies, but committees typically combine scientific experts, governance and legal specialists, and — in leading programmes such as Genomics England — participant or lay representatives who bring the perspective of the people the data describes.

What is the difference between a DAC and an ethics committee?

An ethics committee (or Institutional Review Board) approves the conduct of research involving people; a DAC approves access to an existing dataset. Many DACs require evidence of ethics approval as an input to their own decision — the two are sequential, not interchangeable.

What is the GA4GH Data Use Ontology and why does it matter to DACs?

The Data Use Ontology (DUO) is a GA4GH standard for encoding data use conditions — such as disease-specific or non-commercial restrictions — in machine-readable form, so applications can be automatically pre-matched against a dataset’s permitted uses before human review.

How does a Trusted Research Environment change DAC review?

Instead of releasing a copy of the data, approval grants access to a governed environment where the data stays at source, use is logged, and outputs are checked before release — making the committee’s decision enforceable, observable, and revocable.

Do DACs still matter under the EHDS?

Yes — the EHDS institutionalises the model. Health Data Access Bodies perform DAC-style review, issue data permits, and must provide access only through secure processing environments, aligning EU law with the committee-plus-environment pattern national programmes already use.