Data Sharing and Reuse in a Data Management Plan

By Dr. Zubair Khalid, DVM, MS, PhD · 2026-11-11

By the end of this guide you will be able to write the data sharing and reuse section of a data management and sharing plan (DMSP) that reviewers can evaluate, a repository can accept, and another laboratory can actually reuse. You will inventory the data your project will create, choose formats and standards, select a repository, draft a sharing timeline and reuse terms, estimate the effort, and verify the deposit before submission. Keep four things on hand: your project aims, your funder's data policy page, a file listing from your project folder, and a DMPTool.org account if your institution provides one, since many institutions offer funder-specific templates through it [1].

The goal throughout is data sharing plan reproducibility, meaning a plan whose promised deposit actually supports independent verification rather than a promise that evaporates at the end of the grant.

What Data Sharing and Reuse Mean in a DMSP

A DMSP is a short document, submitted with a grant proposal, that describes what data a project will generate, how the data will be organized and documented, which data will be shared, when, where, and who may reuse them. The NIH Data Management and Sharing (DMS) Policy, in effect since January 2023, requires such a plan from investigators seeking funds for research that generates scientific data [2]. The National Science Foundation has required data management plans with funding applications for years [3]. Other funders follow similar patterns, so the drafting skills below transfer across agencies.

Data sharing means making the data that support your findings available to people outside the project, usually by deposit in a repository or through controlled access. Data reuse means the second and later uses of those files by others. Reuse is the payoff. Open access to data allows other researchers to test the reproducibility of your findings, test new hypotheses, pool individual level data in meta-analyses, and build very large combined datasets for developing and testing new algorithms [4].

Reproducibility, in this context, is the ability of others to independently verify scientific findings by following the same methods and data [5]. A sharing plan is where reproducibility becomes concrete. A plan that names the files, formats, repository, timeline, and reuse terms gives a future reader everything needed to attempt verification. A plan that only promises to share data gives them nothing.

Funders have historically written their requirements around what happens after publication. A review of funder requirements identified 43 distinct topics a comprehensive plan can cover and found that the written requirements emphasized post-publication data sharing rather than upstream activities that affect data quality, provide traceability, or support reproducibility [3]. The steps below deliberately include those upstream activities, because a deposit of undocumented files cannot be reused no matter how open it is.

Two frameworks shape the rest of this guide. The FAIR principles hold that research data should be findable, accessible, interoperable, and reusable [6]. Transparency practices hold that a study protocol, an analysis plan, and analysis code should be shared alongside the data, replacing the "single wrap-up publication" as the only record of a project [7]. There is also an ethical argument for sharing, since research participants are generally supportive of making data publicly available [4].

A Data Sharing Plan for Reproducibility, Step by Step

Seven step flow from inventory through formats, metadata, repository, timeline, budget and the final check.

The walkthrough below uses a running example, a small academic project with tabular results, sequence reads, and analysis code. Replace the details with your own. Each step ends with text you can adapt for a draft plan.

Step 1: Inventory the data your project will create

Open a terminal in your project directory and count files by type.

cd ~/projects/dss-colitis-2026
find data -type f | sed 's/.*\.//' | sort | uniq -c | sort -rn

Expected output looks like this:

  412 csv
   87 fastq
   12 ipynb
    9 R
    3 docx

Then measure total volume.

du -sh data

6.8G    data

Sort the list into three groups. Scientific data are the files needed to validate your findings, here the csv result tables and the fastq sequence reads. Records such as consent documents stay internal. Products such as manuscripts and figures are shared through publication rather than a data repository. The inventory drives every later decision, because file type determines which repository accepts the data and volume determines transfer logistics.

Step 2: Fix formats and write an integrity manifest

Repositories prefer open formats. Export spreadsheets as csv with UTF-8 encoding, keep sequence reads in fastq, and save analysis code as plain text scripts. Then generate a checksum manifest so future users can confirm that the files they download are the files you deposited.

cd data
md5sum *.csv > manifest.md5
head -2 manifest.md5

Expected output, one line per file:

9f86d081884c7d659a2feaa0c55ad815  weights_week12.csv
6b86b273ff34fce19d6b804eff5a3f574  cytokines_batch3.csv

Verify before any transfer:

md5sum -c manifest.md5

A clean check prints OK for every file. A failure prints the filename followed by FAILED and the line md5sum: WARNING: 1 computed checksum did NOT match. Re-export the file, re-transfer, and check again. Line ending conversions during text file transfers are a frequent cause.

Step 3: Write the README and metadata

Metadata are structured descriptions of a dataset, and they are what make a deposit findable and interpretable. Most repositories provide a metadata form at upload, so prepare the content in advance in a README at the project root.

title: "Weekly body weights, DSS colitis model, 2025 cohort"
creators:
  - "Researcher, Alex (ORCID 0000-0002-1825-0097)"
created: "2026-03-15"
license: "CC BY 4.0"
methods: "DSS-induced colitis in C57BL/6J mice, weights recorded weekly for 12 weeks"

Add a data dictionary, a table listing every variable name with its definition, units, and allowed values. Also link the study protocol and the code repository by their persistent identifiers so a reader can move from dataset to method to analysis without asking you.

Step 4: Choose the repository

Match each data group to a repository using the table in the next section, and record the repository by name in the plan. Uncertainty here is common. In a survey of researchers at an academic medical center, only 40 percent felt confident identifying an appropriate repository [1]. Ask your librarian or institutional data steward to confirm the choice before data collection starts.

Step 5: Draft the sharing timeline and reuse terms

Write the timeline as commitments tied to milestones, not vague intentions. A draft paragraph for the plan:

All de-identified datasets, the data dictionary, and the statistical
analysis plan will be deposited in [named institutional repository]
under a CC BY 4.0 license no later than acceptance for publication
and within the final year of the project period. Sequence reads will
be submitted to [named sequence archive] at first publication. The
analysis code that produces each figure will be archived with the
datasets so that every result can be regenerated.

Three parameters matter here. The license sets what others may do with the data, and CC BY 4.0 permits any use with attribution. Timing should align with funder policy, which for NIH-funded work means making scientific data available no later than the end of the award period, and as findings are accepted for publication. The access model separates open deposits from controlled access, where a data use agreement governs each request.

Step 6: Estimate the effort and budget it

Sharing has real personnel costs, and reviewers can tell when a plan ignores them. A useful anchor comes from a library project that built a standardized data management plan and deposit workflow for knowledge synthesis searches in an institutional Dataverse repository. Creating the plan and documentation took about six hours, and each subsequent deposit took 5 to 10 minutes on average [8]. Scale that pattern to your project. A project with one dataset collection and four quarterly deposits needs roughly seven hours of total effort, which you convert to a budget line by multiplying by your institution's hourly rate with fringe benefits.

Add lines for repository fees where they apply, for de-identification work on human data, and for curation time at the end of the project. Budgeting is a known weak point. In the same academic medical center survey, only 38 percent of respondents felt confident budgeting for data management and sharing activities, and 68 percent perceived executing the plan as burdensome [1].

Step 7: Check the plan before submission

Run this checklist against your draft. Every item should be answerable by a stranger reading only the plan.

Data types and estimated volumes are named.
Formats and standards are named.
Metadata and the data dictionary are described.
A repository is named for each data group.
The timeline is tied to milestones.
The access model and license are stated.
Protections for human or sensitive data are described.
Personnel effort and costs are budgeted.
A justification is given for any data that will not be shared.

Then have a colleague or a library data services staff member read it. Many institutions offer consultation for exactly this purpose, discussed below.

If something goes wrong

md5sum: WARNING: 1 computed checksum did NOT match. The file changed between export and deposit. Re-export from the source, avoid tools that alter line endings, and re-run the check.
du: cannot access 'data': No such file or directory. Your terminal is in the wrong directory. Run pwd to see where you are, then cd to the project root or use the full path.
Upload fails on a size limit. Repositories cap individual file sizes, and the caps differ between them. Compress the files, split large tables by batch, or contact repository support for an alternate transfer route.
A csv opens with mangled values. Spreadsheet software can strip leading zeros and reinterpret dates on export. Import columns as text, verify against the raw file, and document the export settings in the README.

Choosing a Repository and Preparing the Deposit

Option	Best for	Access model	Example in practice
Discipline-specific repository	Data in community-standard formats that domain researchers already search	Open or curated	PLANTdataHUB hosts FAIR digital objects called ARCs for plant research [6]
Institutional repository	Outputs tied to your institution, including unusual objects such as search strategies	Open, with searchable metadata	McGill University's Borealis Dataverse collection holds librarian-authored knowledge synthesis searches [8]
Controlled-access repository	Human data requiring oversight of each request	Data use agreement per request	The Yale Open Data Access Project distributes clinical trial data packages [9]
Federated analysis network	Data too sensitive or too large to move	Data stay local, code and aggregate results are shared	A 52-database, 19-country study built on the OMOP Common Data Model [10]

Prefer the repository your field already uses, because discoverability depends on shared conventions. FAIR alignment is the criterion that matters, findable through persistent identifiers and rich metadata, accessible through documented protocols, interoperable through standard formats and vocabularies, and reusable through clear licenses and provenance [6]. Platforms built around FAIR digital objects add continuous quality control as data move from planning to publication [6].

Prepare the deposit as a package, not a pile. The SMART-AF cardiac ablation trial, which enrolled 172 participants across 21 sites, made an independent reproduction possible by sharing the datasets together with a data dictionary, case report files, and the statistical analysis plan through a controlled-access platform [9]. The reproduction analysts could reconstruct the effectiveness and safety analyses because the package was complete. Your deposit should reach the same standard, datasets plus dictionary plus analysis plan plus code.

Sensitive Data, Controlled Access, and Reuse Responsibilities

Human data need a protection strategy written into the plan. De-identification removes or transforms direct and indirect identifiers before release, and the decisions involved deserve explicit documentation. One clinical research team preparing an open release of structured datasets weighed de-identification options, described the limitations and biases their algorithm introduced, and argued for transparent disclosure of those decisions with the dataset, noting that re-identification risks are changing in the era of large language models [11]. Write the same disclosure into your plan, covering what was removed, what was generalized, and what residual risk remains.

Controlled access is the middle path between open deposit and no sharing. A repository holds the data and releases them to approved requesters under a data use agreement. Risk frameworks for sharing group the concerns into legal, technical, reputational, and commercial categories, and the barriers reported in practice range from misinterpretation of privacy regulation to a lack of technical personnel able to execute large transfers [2]. Naming the specific risk that applies to your data, and its mitigation, is stronger than a blanket refusal to share.

When data cannot move at all, share the analysis instead. Federated designs keep data at each site and exchange only analytical code and aggregated results, an approach demonstrated at scale on a standardized common data model [10]. Sensitive programs can adopt a verification strategy with a centralized data storage and exchange platform, quality assurance and quality control of data collection, and an archival software and data repository, as implemented in one human performance research program [12].

Reuse responsibilities do not end at the provider. Recipients of individual participant data are expected to protect participant privacy, and one recommendation from a focus group study is that recipients proactively share a secure data management plan and evidence of ethical oversight with the data provider [13]. If your project will reuse other people's data, budget time to obtain approvals and say so in your plan.

Budgeting, Effort, and Institutional Support

Institutional readiness shapes how hard this work is. A survey of 155 researchers at an academic medical center, with 55 responses, found that 67 percent understood the NIH DMS Policy but only 47 percent felt comfortable developing a plan, 29 percent had used DMPTool.org, and 87 percent wanted tailored templates [1]. Those numbers describe a typical starting point, and they explain why funders and libraries have built support services around plan writing.

Support to look for includes three things. Many institutions employ data stewards, staff who support research data management across projects, although a national survey in Italy found such roles are often informal and not formally recognized in job titles [14]. Library data services and research office staff can review a draft plan, and DMPTool.org provides funder-templated planning [1]. If your institution lacks these services, the funder's program officer and the repository's help desk are the next lines of support.

Common Mistakes and Limitations

The most common mistakes in a data sharing plan for reproducibility are predictable, and each has a fix.

Planning sharing only after publication. A plan built around the final deposit misses the upstream decisions that make data traceable and reusable. Decide file organization, naming, and documentation before data collection begins.
Promising sharing without executing it. The gap between intent and deposit has a name, Open Data in Appearance Only, defined as the intent of data sharing without the occurrence of actual data sharing [2]. Name the repository, set internal deadlines tied to manuscript milestones, and assign a responsible person.
Depositing data without the dictionary or the analysis plan. Datasets alone rarely support verification. Package the protocol, analysis plan, and analysis code with the data [7].
Treating de-identification as a checkbox. Write down what was removed, what was generalized, and what residual risk remains, and disclose the limitations of your approach [11].
Ignoring the recipient side. If your lab will reuse other people's data, plan for privacy protection, documented ethical oversight, and the resources to manage the data securely [13].
Underestimating sensitive data. Uncertainty in managing sensitive data was a reported challenge among researchers surveyed at an academic medical center [1]. Consult your institutional review board and data services early.
Choosing the repository after collection. Formats that seemed convenient during analysis can be unusable for deposit. Confirm accepted formats and size limits before the experiment starts.

Limitations. Policies differ across funders and institutions, and requirements change. Treat this guide as a drafting framework and confirm specifics against your funder's current policy and your institution's data services before submission.

Reproducibility Tips for Your Data Sharing Plan

These reproducibility tips for a data sharing plan come from programs that had to make verification work in practice.

Share the full chain, protocol, analysis plan, code, and data, rather than the final dataset alone.
Build quality assurance and quality control into data collection, and use a centralized storage platform so every team member works from the same files [12].
Use containerized workflows and standardized processing pipelines so others can run your analysis in the same environment [16].
Adopt platforms that treat data as FAIR digital objects with continuous quality control from planning through publication [6].
For multi-site studies, standardize the analytics and divide responsibilities explicitly, as large federated studies do [10].
Version your code and archive it with a persistent identifier at deposit, so each figure can be regenerated from the archived state.
Use ISO 8601 dates (YYYY-MM-DD) and file names without spaces, so listings sort chronologically and survive every operating system.

Where the Plan Fits in Grant Proposal Planning

Treat the data sharing plan as part of grant proposal planning from the first outline, not as an attachment written the night before the deadline. NIH requires a DMS Plan with proposals for research generating scientific data under the policy in effect since January 2023 [2], and NSF requires a data management plan with applications [3]. Reviewers read the plan as evidence of project rigor, and the plan's budget and timeline entries must match the rest of the proposal. Write the plan while designing the study, when decisions about formats, standards, and repositories are still cheap to change [15].

If your campus offers a research grant writing course, bring a draft plan to it, and pair the course with a consultation at the library or research data services office. The combination of funder templates and experienced review addresses the support researchers most often request [1].

Frequently Asked Questions

What does data sharing and reuse mean in a DMSP?

Data sharing is making the data that support your findings available outside the project, and reuse is the later use of those data by others for verification, new analyses, or pooling. Your DMSP states what you will share, where, when, and under what terms.

Do I have to share all of my data?

No. Funders generally require sharing of the scientific data needed to validate findings and allow exclusions for ethical, legal, or technical reasons when you justify them. Records such as consent documents typically stay internal.

When does the NIH DMS Policy expect data to be shared?

Under the policy in effect since January 2023, scientific data should be made available as findings are accepted for publication and no later than the end of the award period. Your plan states the specific milestones.

What belongs in the sharing and reuse section at minimum?

Data types, formats and standards, a named repository, a timeline tied to milestones, an access model and license, protections for sensitive data, and the budgeted effort. Add a justification for anything you will not share.

How do I choose a repository?

Prefer the repository your field already searches, confirm it assigns persistent identifiers and supports rich metadata, and check accepted formats and size limits before data collection. Your librarian or data steward can confirm the choice.

Can I share human participant data?

Yes, either as de-identified open data or through controlled access with a data use agreement. Document your de-identification decisions, their limitations, and the residual re-identification risk.

What makes data reusable rather than merely available?

Documentation. A data dictionary, the statistical analysis plan, the protocol, and the analysis code turn a downloadable file into a dataset someone can verify and extend.

How long does preparing a deposit take?

Plan for a few hours to build documentation and metadata the first time, then minutes per deposit once the workflow exists. Put both in the budget.