dbGaP (the Database of Genotypes and Phenotypes) is the NIH/NCBI repository that operates under a two-tier model: an open-access tier for aggregate, non-identifiable study documentation, and a controlled-access tier for individual-level genotype-phenotype data. That split creates two distinct research-administration workflows that are easy to conflate but run through different NIH systems, different signers, and different timelines. This guide covers both: how a data-generating study submits its genomic and phenotypic data to dbGaP, and how a secondary-use investigator requests controlled-access data through a Data Access Request (DAR). For the underlying concept and access-tier mechanics, see the dbGaP dictionary entry; for the EU’s equivalent system, see EGA: The EU’s Controlled-Access Counterpart to dbGaP.
Submission vs. data access request: which workflow applies to you
These are two different roles interacting with two different parts of dbGaP. Confirm which one applies before starting.
| Submitting a study’s data | Requesting controlled-access data (DAR) | |
|---|---|---|
| Who does this | The data-generating investigator/study team, typically an NIH grantee under the Genomic Data Sharing (GDS) Policy | A secondary-use investigator who wants to analyze data someone else already deposited |
| System | dbGaP Submission Portal (submit.ncbi.nlm.nih.gov/dbgap) | dbGaP Authorized Access System |
| Identity check | Coordinated with an assigned NIH Genomic Program Administrator (GPA) | PI’s eRA Commons account |
| Core document | Study Config, phenotype Dataset/Data Dictionary files, Study Data Outline (SDO) | Data Access Request describing proposed research use, plus the Data Use Certification (DUC) Agreement |
| Institutional sign-off | Institutional Certification (confirms IRB approval and consent scope for the data being submitted) | eRA Commons Signing Official co-signature |
| Who approves | dbGaP staff / NIH Institute or Center processing the submission | The relevant NIH Data Access Committee (DAC) for that study |
| Typical processing time | Sequence metadata: 2-3 business days; sequence files: 3-5 business days (varies with volume and size) | Access period runs for one year once approved; DAC turnaround varies by committee |
Submitting a study’s data to dbGaP
A study’s genomic and phenotypic data goes to dbGaP because a data-sharing obligation requires it — most commonly the NIH Genomic Data Sharing (GDS) Policy, which since January 25, 2015 has required NIH-funded investigators generating large-scale human or non-human genomic data (GWAS, SNP arrays, whole-genome/exome sequencing, transcriptomic, epigenomic, and related data types) to deposit it in an NIH-designated repository as a term of the award.
- Register the study. Registration happens through the dbGaP Submission Portal and is coordinated with an assigned NIH Genomic Program Administrator (GPA), who works with the study team to set up the submission framework before any files move. A study cannot submit data before it is registered.
- Complete the Study Config. A web form in the portal capturing the study description, methods, and indexing information used to build the public study page.
- Prepare the phenotype files. These are submitted as paired Dataset and Data Dictionary files and typically include Subject Consent, Subject Sample Mapping, Subject Phenotypes, Sample Attributes, and Pedigree data where applicable. Consent-group coding here is what later lets the Data Access Committee enforce the original participants’ consent boundaries during DAR review.
- Complete the Study Data Outline (SDO). This asserts, in the Submission Portal, which data types the study will submit (phenotype, molecular/sequence, association analyses, study documents).
- Submit molecular, sequence, and association-analysis data as applicable to the study design, through the Submission Portal rather than email — a privacy control, not just a convenience, since it keeps individual-level files off unencrypted channels.
- Processing and preview. dbGaP processes and validates submitted files; the study team can preview how the release will appear before it goes live.
- Release. Once processing and any required institutional certification are complete, the study record splits into its open and controlled-access components per the plan set out in the Data Dictionary and consent coding.
Last verified 2026-08-16 against NIH/NCBI’s dbGaP submission guide.
Requesting controlled-access data: the Data Access Request (DAR) process
Reusing someone else’s dbGaP-deposited controlled-access data is a research-administration workflow with real institutional steps, not a self-service download.
- PI authentication via eRA Commons. The requesting Principal Investigator, and any co-investigators who need direct access, must have an eRA Commons account and log into the dbGaP Authorized Access System with it before a request can be built.
- Build the request. The PI selects the study/dataset, states the proposed research use, and agrees to the Data Use Certification (DUC) Agreement and the Genomic Data User Code of Conduct — covering confidentiality, permitted use, publication acknowledgment of the original data-generating investigators, and a prohibition on re-identification attempts.
- Institutional co-signature. The request must be co-signed by the institution’s eRA Commons Signing Official, typically in the sponsored-programs or grants office, before it reaches NIH. This is the step research administrators specifically own, and it’s worth confirming your institution’s Signing Official workflow before the PI is ready to submit, not after.
- Data Access Committee review. The relevant NIH DAC — there are many, organized by the institute or consortium overseeing a given dataset, not one central committee — reviews the request against the study’s data use limitations and the boundaries set by the original participants’ informed consent (for example, disease-specific research only, or no commercial use). Approval makes the PI an “Approved User.”
- Annual renewal or close-out. Approved-user access runs on a one-year data access period. Before it expires, the PI must submit either a Project Renewal (with a Progress Update summarizing how the data were used and any resulting publications) or a Close-out. The account is suspended if neither is submitted within 42 days of the expiration date.
Checklist: before a PI submits a DAR
- PI has an active eRA Commons account and has logged into the dbGaP Authorized Access System at least once
- Proposed research use is described specifically enough to be checked against the target study’s data use limitations (not just “secondary analysis”)
- Institution’s Signing Official is identified and has bandwidth to co-sign before the funding or manuscript deadline that’s driving the request
- Any co-investigators who need direct data access are named in the request, not added informally afterward
- A plan exists for acknowledging the original data-generating study in any resulting publication, per the DUC’s terms
- A calendar reminder is set well before the one-year anniversary of approval, to avoid the 42-day suspension window on a missed renewal or close-out
Data Use Certification (DUC) obligations after approval
Approval is not the end of the compliance obligation — the DUC Agreement binds the Approved User and their institution for as long as they hold the data. Core obligations include restricting use to the certified research purpose, not attempting to re-identify participants or contact them, not redistributing the data to anyone not covered by the approved request, and acknowledging the original study in publications. If a security incident occurs — unauthorized sharing, a breach, or inadvertent release that could compromise confidentiality — the DUC requires notifying the relevant DAC promptly (commonly cited as within 24 hours of identifying the incident), followed by a detailed written report shortly after. See Data Security Incident Notification Requirements and the data breach response plan template for how this fits into a broader institutional incident-response process; the exact reporting cadence is worth re-confirming against the current DUC template text for your specific study, since template language is revised periodically.
How dbGaP submission fits NIH’s broader data-sharing policy landscape
A genomics-generating NIH award is typically subject to two overlapping obligations at once: the general NIH Data Management and Sharing (DMS) Policy, which requires a data management and sharing plan for nearly all NIH-funded research producing scientific data, and the more specific GDS Policy, which requires large-scale genomic data to go to an NIH-designated repository with institutional certification. A study’s DMS Plan for a genomics-generating award should name dbGaP (or another applicable NIH-designated repository) as the deposit target and describe how controlled-access review will be handled — not just assert that data will be “shared.” dbGaP itself sits within a wider landscape of NIH-designated and disciplinary genomic repositories: GenBank and the Gene Expression Omnibus (GEO) handle open-access sequence and expression data without individual-level linkage, while dbGaP is specifically where individual-level genotype-phenotype linkage goes. Outside NIH-funded genomics, comparable controlled-access models appear in the EU’s European Genome-Phenome Archive (EGA), the All of Us Researcher Workbench‘s tiered-access model, PhysioNet’s credentialed access for clinical signal data, and Vivli’s clinical-trial data request process. When evaluating any repository’s trustworthiness against dbGaP’s model, CoreTrustSeal certification and the re3data registry are the standard reference points; see also Research Repositories vs. Archives for the broader distinction. If your data can’t be fully de-identified or openly shared but doesn’t fit dbGaP’s genomic scope, it likely belongs in a general sensitive-data repository instead, governed by its own data use agreement.
Frequently asked questions
Who at my institution should be the eRA Commons Signing Official for a dbGaP DAR?
This is normally the same Signing Official role your institution already uses for other eRA Commons functions, most often based in the sponsored-programs or grants office. See eRA Commons roles for how the Signing Official role differs from PI and Account Administrator roles.
How long does dbGaP Data Access Committee review take?
There is no single published turnaround time, because each dataset’s DAC sets its own review cadence and there are many DACs across NIH institutes and consortia. Build DAC review time into any grant or manuscript timeline that depends on the data, rather than assuming a fixed number of business days.
What happens if a DAR renewal or close-out is missed?
Access is suspended if neither a Project Renewal nor a Close-out is submitted within 42 days of the one-year access period’s expiration date.
Can data submitted to dbGaP ever move to fully open access?
Only the parts of a study that were never individual-level to begin with — aggregate allele-frequency tables, summary statistics, and study documentation — are open by default. Individual-level genotype-phenotype data stays in the controlled-access tier because de-identification alone does not remove its re-identification risk.
Does a purely clinical, non-genomic dataset belong in dbGaP?
No. A survey-based phenotype study with no genotyping data does not belong in dbGaP regardless of funder or sensitivity; it would instead go to a general-purpose or discipline-specific data repository, or a sensitive-data repository if it carries other confidentiality constraints.
Last verified 2026-08-16 against NIH/NCBI’s dbGaP submission guide and the existing CASRAI dbGaP dictionary entry (sourced from the NIH Genomic Data Sharing Policy and dbGaP Data Use Certification Agreement documentation). NIH DUC template language and exact reporting timelines are revised periodically — re-confirm against the current DUC text for your specific study before treating a specific business-day count as binding.
