Data Availability Statements: 6 Templates & Tips

Journals and funders increasingly want to know where the data behind your findings can be found. A data availability statement gives that answer in just a few lines. This guide shows how to write one, with six ready-to-use templates, worked examples, advice on choosing a repository, the FAIR data principles, handling restricted data and avoiding weak “on request” statements.

Understanding the Data Availability Statement

A research data availability statement is a brief section of a paper that explains to readers where the data underlying the findings are located and on what conditions, or why sharing is impossible. It normally sits after the main text, close to the funding and conflict-of-interest statements. Numerous journals and funders now demand one, even where depositing the data itself is voluntary.

The Reason Journals Request One

• Verification: results can be checked and repeated by other researchers.
• Reuse: existing data can address fresh questions without collecting more.
• Transparency: readers learn what evidence exists, even when access is restricted.
• Funder rules: numerous funders anticipate data sharing plans and statements.

Six Statement Templates

Select the template that is true for your study, complete the brackets and adjust the wording where necessary. These six types follow the JMVRA data availability policy:

Worked Examples

Choosing a Repository

Start with a subject repository common in your field, then an institutional repository, and after that a reputable general-purpose repository. Check for persistent identifiers (DOIs), clear licences, long-term preservation and, when needed, controlled access. The re3data registry can help you locate repositories by subject. Settling on one trusted home for your files is better than scattering them across many sites.

FAIR Data Principles

The FAIR principles describe data that are Findable, Accessible, Interoperable and Reusable. To follow them, deposit with a DOI and rich metadata, choose open formats (CSV instead of proprietary binaries), describe the variables and methods in a codebook, and add an unambiguous licence like CC0 or CC BY.

If the Data Cannot Be Shared

Protecting participants always outranks openness. Restrictions that are stated clearly and honestly are fine, but vague ones are not.

Trouble with the “On Request” Statement

“Available on reasonable request” is the weakest choice, since requests frequently go unanswered once email addresses change or authors move on. Rely on it only if you will really reply, provide a lasting contact (a role email or institutional address) and, whenever possible, favour a repository instead.

Comparing Weak and Strong Statements

Click through every link before you submit, confirm that the repository record is public (or embargoed until publication), and verify that the statement agrees with the methods section. A colleague opening the links on another device is a quick extra test.

Sharing Code, Materials and Protocols

Analysis code seldom raises sensitivity concerns and greatly helps reproducibility. Place it in a public code repository or deposit it with a DOI, and refer to it in the statement. Supplementary files can carry questionnaires, protocols and materials.

Getting Your Data Ready to Share

Think about sharing from day one: consent forms should permit it, and files should be kept tidy as the work proceeds. Before you deposit, strip direct identifiers, examine indirect ones, write a README and codebook, and select a licence. Reviewing the folder as an outsider would often reveals gaps you had missed.

JMVRA’s Approach to Data Availability

According to JMVRA’s data availability policy, authors are encouraged but not required to share data, yet a data availability statement is compulsory. Choose one of the six templates above, apply FAIR practice wherever you share, and be honest about restrictions. Put the statement where the journal template and guidelines indicate.

Share Your Research Through JMVRA

Your At-a-Glance Checklist

1. TrueSelect the honest template
2. SpecificGive repository and DOI
3. RestrictionsExplain why, add a contact
4. CodeLocation given
5. LinksTested
6. ConsentAllows sharing

Practical Tips for Writing a Data Availability Statement

A good statement tells readers exactly where your data are and how to reach them. Use these habits while drafting, so the statement is accurate and easy to check when reviewers read it.

• Write it while collecting data. Decide early where files will be stored and who may see them. Drafting the statement during the project avoids vague promises made in a rush at submission.
• Name the exact location. Give the repository, the record title and a persistent link rather than saying data are available online. A reader should reach the right dataset without searching or guessing.
• Explain any restriction plainly. If consent forms, privacy or commercial agreements prevent open sharing, say which rule applies and who decides on access. Honest reasons are respected far more than silence.
• Describe file formats and documentation. Include a short readme that explains column names, units, missing values and software needed. Data nobody can interpret do little good, even when technically open.
• Check the statement before resubmission. Whenever you revise the paper, confirm that every dataset mentioned still exists, opens correctly and matches the version analysed in the final manuscript.

Make your statement specific, verifiable and honest about limits, so that anyone can locate the data you describe.

Questions Researchers Often Ask

In Summary

The best data availability statements are brief, truthful and precise. Settle your sharing plan early, deposit data and code with DOIs where possible, document them properly, restrict access only for real reasons and state those plainly, and check each link before you submit. Statements this clear make your research simpler to trust and reuse.

References and Further Resources

• re3data registry of research data repositories
• GO FAIR: FAIR principles
• JMVRA data availability policy