How to Handle Embargoes in Data Sharing: A Practical Guide

By Dr. Zubair Khalid, DVM, MS, PhD ·

How to Handle Embargoes in Data Sharing: A Practical Guide

By the end of this guide you will be able to read a funder or journal data policy, decide what kind of embargo fits your dataset, calculate the exact release date, write a data availability statement that matches your plan, and choose a repository with the right access controls. You will also know the mistakes that most often cause delayed publications, failed deposits, and broken promises to participants.

Have three things on hand before you start: the data sharing policy from your funder, the data policy from your target journal, and an account on the repository you expect to use. If your study involves human participants, also have your informed consent forms and institutional review board (IRB) protocol number available, because both can constrain what you are allowed to share and when.

What a Data Embargo Is (and What It Is Not)

An embargo in research data sharing is a scheduled delay between the moment data are deposited in a repository and the moment they become publicly visible or downloadable. During the embargo window, the data sit in the repository but access is restricted. The restriction usually lifts on a fixed calendar date or on a trigger event such as publication of the associated paper.

An embargo is not the same thing as controlled access. Controlled access means a repository verifies that each requester is qualified and agrees to terms before releasing data, and that verification can apply for the entire life of the dataset. An embargo is temporary by design. A dataset can be both embargoed and controlled access at the same time, which is common for human genomic data.

An embargo is also not secrecy. Research data sharing under embargo still means the data have a persistent identifier, documented metadata, and a stated release date that other researchers can see and plan around. The point is to balance two legitimate interests: the data producers need time to analyze their own results before others can scoop them, and the community needs timely access to data it helped fund. The National Institutes of Health (NIH) genomic data sharing (GDS) policy explicitly tries to strike this balance, requiring rapid release of genotypic and phenotypic data from both human and model-organism studies while allowing embargo periods so producers have time to analyze their own data [1].

Who Sets Embargo Rules: Funders, Journals, and Repositories

Embargo obligations stack. A single dataset can be governed by three overlapping policies at once, and you need to satisfy the strictest applicable rule.

Funder policies

Funders write the broadest rules. The NIH GDS policy applies to genotypic and phenotypic data from human studies and from model-organism research, and it expects data submission shortly after data generation with an embargo period protecting the producers' analysis window [1]. Read your funding opportunity announcement and the data management and sharing plan you submitted with your application. Those documents tell you whether an embargo is permitted, how long it can run, and where the data must be deposited.

Journal policies

Journals influence behavior through what they require at submission. The International Committee of Medical Journal Editors (ICMJE) required a data sharing statement (DSS) from submissions reporting clinical trials starting July 1, 2018. A cross-sectional study of 487 clinical trials published in JAMA, Lancet, and NEJM between July 1, 2018 and April 4, 2020 used these statements to characterize current data sharing rates, practices, and norms among trialists and sponsors, and it measured both what authors declared about data availability and what was actually available in repositories [2]. If you submit a trial report to a journal with a DSS requirement, your statement must describe whether and when individual participant data will be shared, where, and under what access conditions.

Journal policy stringency measurably changes author behavior. A study of 1,250 articles published between 2023 and 2025 in 25 American Psychological Association (APA) journals estimated overall self-reported data sharing at 30.3 percent, and found that only 15.0 percent of articles reported shared data in journals with no data sharing policy, with much higher rates under stricter policy levels [3]. The practical lesson for you is to check the journal's policy level before submission, because journals that merely ask authors to reveal whether they shared data produce far less sharing than journals that require it.

Repository controls

Repositories enforce embargoes mechanically. A repository can hold files invisible until a release date, restrict them to registered users, or route them through a data access committee, as the NIH-controlled Database of Genotypes and Phenotypes (dbGaP) does for genome-wide association study and sequencing data [4]. When you deposit, the settings you choose for visibility and access determine how your embargo is actually enforced, so choose them deliberately rather than accepting defaults.

Data Sharing Embargo Policy Guide: Step by Step

This walkthrough takes you from reading policies to a dataset sitting in a repository with a scheduled release date. Work through the steps in order, because decisions in early steps constrain later ones.

Step 1: Inventory your obligations

List every policy that touches your dataset. For each, record four facts: whether an embargo is allowed, the maximum permitted length, the required repository, and the required statement wording. A simple table in your project notes is enough.

Policy sourceWhat to look forWhere to find it
, -, -, -
FunderEmbargo length limits, mandated repositories, timing of depositFunding announcement and your approved data management and sharing plan
JournalData sharing statement requirements, embargo tolerance, verification expectationsAuthor guidelines and ICMJE-based DSS templates
RepositoryAccess models, embargo scheduling features, metadata requirementsRepository documentation and submission portal
IRB / consentWhether participants consented to deposit, secondary use limits, recontact rulesConsent forms and your IRB protocol

If two policies conflict, the more restrictive one usually wins. Consent limits are the clearest example. In a survey of the International Genetic Epidemiology Society (IGES) membership about dbGaP experiences, 31 percent of respondents who had contributed data reported local IRB restrictions on data release, and another 15 percent had to reconsent study participants before depositing [4]. If your consent forms do not cover deposit, resolving that takes months, so start before you write the manuscript.

Step 2: Choose the repository and access model

Decision path asking whether data are human genomic, whether consent limits release, and whether the funder mandates a repository.

Your funder may mandate a repository. Genomic data under the NIH GDS policy go to NIH-designated systems such as dbGaP, which runs an application process in which a requesting investigator, their institutional signing official, and a data access committee all play roles [4]. If no repository is mandated, compare repositories on four criteria: whether they support scheduled embargo release, whether they assign a persistent identifier before the embargo lifts, whether they support the metadata standards of your field, and whether they accept the data types you have. The repository comparison section below walks through the main categories.

Step 3: Set and calculate the embargo window

Worked calculation adding a 12 month embargo to an acceptance date of 2026-06-15 to give a release date of 2027-06-15.

Typical embargo lengths range from a few months to about a year for general-purpose data, and funder policies may set specific limits for specific data types. Whatever length you choose, compute the release date the day you deposit, and record it in at least two places: the repository metadata and your own project tracking file.

Compute the date with Python:

from datetime import date
from dateutil.relativedelta import relativedelta

acceptance_date = date(2026, 6, 15)
embargo_months = 12
release_date = acceptance_date + relativedelta(months=embargo_months)

print(f"Deposit: {acceptance_date.isoformat()}")
print(f"Embargo: {embargo_months} months")
print(f"Release: {release_date.isoformat()}")

Expected output:

Deposit: 2026-06-15
Embargo: 12 months
Release: 2027-06-15

Or with standard command-line tools:

date -d "2026-06-15 + 12 months" +%F

Expected output:

2027-06-15

Watch for month-end edge cases. Adding 12 months to August 31 gives August 31 of the following year in most libraries, but adding one month to January 31 gives February 28 or 29 depending on the year. If your acceptance date falls on the 29th, 30th, or 31st, verify the computed release date by hand and state the date explicitly in your data availability statement rather than writing "12 months after publication."

Step 4: Prepare files and metadata before acceptance

Deposit-ready data are rare at manuscript submission, and rushed preparation is the main reason deposits lag behind publication. Before the paper goes in, assemble:

  • Analysis-ready data files in open formats (CSV for tables, FASTQ and BAM for sequencing reads, HDF5 or similar for large arrays).
  • A README describing each file, each column, and the software versions used.
  • Metadata sufficient for a stranger to interpret the data, including study design descriptions required by your repository.
  • A de-identification check for human data, documented in your IRB protocol.

A machine-readable tracking record keeps this organized:

# embargo_plan.yaml
dataset_id: "project-alpha-2026"
manuscript_title: "Example transcriptomic study"
acceptance_date: "2026-06-15"
embargo_months: 12
release_date: "2027-06-15"
repository: "controlled-access repository per funder policy"
access_model: "controlled"
consent_verified: true
irb_protocol: "IRB-2025-0142"
contact: "[email protected]"

Validate that the YAML parses before you rely on it:

python -c "import yaml; print(yaml.safe_load(open('embargo_plan.yaml'))['release_date'])"

Expected output:

2027-06-15

Step 5: Write the data availability statement

The statement must match what you actually plan to do, because journals now verify claims against repositories. In the ICMJE-required environment, researchers analyzed declared data availability alongside actual repository availability, which is only possible if statements make checkable commitments [2]. Write concrete sentences, for example:

The individual participant data supporting the results in this article will be deposited in [repository name] upon publication and will be available after a 12-month embargo ending 2027-06-15. Access to de-identified data will be granted to qualified researchers through the repository's data access process. Proposals should be directed to [email protected].

If some data cannot be shared because of consent restrictions or IRB conditions, say so in the same statement and name the restriction. Vague statements such as "data available on reasonable request" are the weakest option, and they are also the hardest to honor when requests arrive years later.

Step 6: Deposit and schedule the embargo

Deposit as soon as your repository allows, even before publication if the repository supports pre-release holds. During submission you will typically set:

  • Visibility (public immediately, embargoed until a date, or controlled access).
  • The embargo end date, using the release date from Step 3.
  • Licenses and access terms.
  • A persistent identifier, which you should cite in the manuscript even while the dataset is embargoed so readers can see that a citable object exists.

For controlled-access repositories such as dbGaP, expect an administrative process rather than a simple upload. Survey data show the friction is real. Among IGES respondents who had received dbGaP data, only 32 percent found the application process easy, although most, 75 percent, did receive data within five months [4]. If your own project will depend on requesting controlled data from others, build a comparable waiting period into your timeline, and identify your institutional signing official early, since respondents specifically cited difficulty finding one [4].

Step 7: Verify, monitor, and release

After deposit, confirm three things: that the dataset record is visible with its metadata even while files are embargoed, that the stated release date in the repository matches your tracking file, and that the persistent identifier resolves. Then set two calendar reminders, one a month before the release date to confirm nothing has changed and one on the release date to verify the data became public. If publication is delayed past your planned release date, contact the repository to extend the embargo, and update your data availability statement at proof stage if needed.

Data Repository Comparison: Choosing Where Data Waits Out the Embargo

Repositories differ mainly in who controls access and how the embargo is enforced. Match the category to your data type and consent situation.

Repository categoryAccess modelHow the embargo is enforcedBest suited for
, -, -, -, -
Funder-mandated controlled-access repositories (for example dbGaP for human genomic data)Application reviewed by a data access committeeData visible in catalog, files released only after approval, submission timing set by funder policy [1]Human genomic and phenotypic data with consent-based restrictions
Domain-specific open repositoriesPublic download after embargo liftRepository holds files invisible until a scheduled dateModel-organism data, sequencing data, and community standards data
Generalist institutional or disciplinary repositoriesPublic download after embargo lift, sometimes registration requiredScheduled release date attached to the recordDatasets without a natural domain repository, mixed data types
Journal-supervised supplementary dataPublic with the articleNo independent embargo, data appear when the article doesSmall datasets with no secondary reuse planned

Three criteria should drive the final choice. First, permanence: the repository must assign a persistent identifier that survives the embargo and any URL changes. Second, enforcement fit: an embargo based on participant consent needs access control, not just a delay, because a delayed public release of identifiable data still violates the consent. Third, verification: if your journal checks data availability statements against repositories, depositing somewhere checkable protects you at revision time. The evidence that policy stringency drives actual sharing behavior [3] applies here too, because repositories that make compliance easy are the ones you will actually use on schedule.

Data Sharing Embargo Policy Guide Tips

These tips come from the failure modes that recur across funder, journal, and repository policies.

Start policy reading at award time, not submission time. Your data management and sharing plan is a commitment you made to the funder. Rereading it the week before submission produces inconsistent statements, and inconsistent statements are what audits and follow-up studies flag [2].

Ask for the longest defensible embargo. In the IGES survey of dbGaP users, a majority of respondents, 56 percent, disagreed that the publication embargo period was sufficient, and the survey authors responded by recommending longer embargo periods [4]. If your funder policy allows a range, take the upper end only if you can justify it, and document the justification in your data management plan.

Decouple the embargo from the publication date when you can. Publication dates slip. A release date anchored to a fixed calendar date is predictable for the community and easier for a repository to enforce than one contingent on an event outside your control.

Cite the dataset before it is public. Including the persistent identifier in the manuscript, with a note that the dataset is embargoed until a stated date, lets other researchers anticipate the release and lets reviewers verify that a deposit plan exists rather than trusting a promise.

Budget administrative time for controlled access in both directions. Deposit side, plan for IRB review and possible reconsent, which affected contributors in the dbGaP experience [4]. Request side, plan around the roughly five-month median wait reported by most successful applicants. Both sides reward early starts.

Write the statement last, from the tracking file. Your data availability statement should be a plain-language rendering of embargo_plan.yaml, not an aspiration. When the journal, repository, and statement all describe the same dates and conditions, verification is trivial and your record stays clean.

Common Mistakes and Limitations

Avoid these specific, practical errors.

Treating the embargo as optional after acceptance. Once a data availability statement with dates appears in a published article, the dates are commitments. Journals in the ICMJE framework collect these statements precisely so that declared plans can be compared with actual repository availability [2]. A missed release date is discoverable and persistent.

Confusing embargo with anonymization. An embargo delays access, it does not remove identifying information. Before depositing any human data, complete de-identification or confirm that your consent and IRB approvals cover controlled-access sharing of the data as they exist. IRB restrictions and reconsent requirements were among the top barriers reported by actual depositors [4].

Assuming stricter talk means more sharing. Self-reported data sharing in APA journals averaged 30.3 percent across 1,250 recent articles, and journals with no policy saw only 15.0 percent [3]. Policies move behavior, but a majority of articles in even policy-covered venues still report no shared data, so never assume a dataset exists just because a paper implies it.

Choosing embargo length by habit. A 12-month default may be too short for a dataset feeding multiple papers and too long for a dataset the community needs urgently. Justify the length against your actual analysis plan and your funder's limits.

Ignoring the application burden your users will face. If you deposit into a controlled-access repository, your downstream users inherit the access process. The dbGaP experience shows most applicants eventually receive data, with 75 percent reporting receipt within five months, but only about a third found the process easy, and identifying a signing official was a recurring obstacle [4]. Document in your README how to apply and who to contact, so the embargo does not become a wall.

Letting the tracking file drift. If the acceptance date changes, recompute the release date everywhere at once, in the repository settings, the tracking file, and the proof of the data availability statement. Three inconsistent dates are worse than one.

A note on limits of this guide. Policies vary by funder, journal, repository, and institution, and this guide cannot substitute for the specific text of your own obligations. Individual studies involving human participants also need review by your IRB before any deposit decision.

Frequently Asked Questions

What is a data sharing embargo?

A data sharing embargo is a scheduled delay between depositing data in a repository and making them publicly available. The dataset record and metadata may be visible during the embargo, but files stay restricted until a fixed release date or a trigger such as publication.

How long should a data embargo last?

Use the shortest window that still gives your team time to publish its primary analyses, because a majority of surveyed dbGaP depositors felt the standard publication embargo was not long enough, and the survey authors recommended longer periods [4]. Check your funder policy first, since it may set or limit the length.

What is the difference between an embargo and controlled access?

An embargo is temporary, ending on a date or event, while controlled access is a standing requirement that each requester qualify and agree to terms. Human genomic data often have both, sitting behind an access committee during and after the embargo window [1].

Do all journals require a data sharing statement?

No, but leading medical journals that follow the ICMJE requirement have asked for data sharing statements from clinical trial submissions since July 1, 2018 [2]. Policy stringency varies widely across journals, and stricter policies are associated with higher rates of reported sharing [3].

What happens if I miss my stated release date?

The mismatch between your published statement and the repository becomes visible, and journals compare declared availability against actual deposits [2]. If publication is delayed, contact the repository to adjust the embargo before the scheduled date, and correct the statement at proof stage.

Can I embargo data if participants consented to public sharing?

Usually yes, because an embargo only delays access that consent already permits. Check your consent forms and IRB protocol before deposit, since some studies carry IRB restrictions on release or require reconsent before any deposit [4].

When should I deposit my data relative to publication?

Deposit as early as your repository allows, ideally before acceptance if the repository supports pre-release holds. Early deposit lets you reserve a persistent identifier, schedule the embargo accurately, and cite a real dataset in the manuscript.

How do I verify my embargo is set up correctly?

Check that the dataset record is visible with complete metadata, that the repository's stated release date matches your computed date exactly, and that the persistent identifier resolves. Recheck one month before and on the release date itself, and confirm files become accessible as scheduled.

Sources

  1. NIH's genomic data sharing policy: timing and tradeoffs.
  2. Evaluation of Data Sharing After Implementation of the International Committee of Medical Journal Editors Data Sharing Statement Requirement.
  3. Self-reported availability of research data in American Psychological Association journal articles: a cross-sectional investigation.
  4. Practical barriers and ethical challenges in genetic data sharing.