If you're a startup founder applying for an NIH SBIR with proprietary data, you have probably read about the NIH data sharing plan SBIR requirement and panicked. The Data Management and Sharing Policy says you need to submit a plan describing how you'll share your data. So are you about to hand your competitive moat to every lab and competitor the moment you accept federal funding?
No.
Buried in the Small Business Act is a 20-year data protection window written specifically for SBIR and STTR awardees. Your NIH data sharing plan for SBIR can invoke this carve-out, satisfy the policy, and keep your proprietary data protected for two decades. Most founders do not know it exists. Most grant writers do not either.
Do I Have to Share My Data If I Get an NIH SBIR?
Short answer: You must write a Data Management and Sharing Plan. You do not have to hand over your proprietary data. SBIR Data Rights under 15 U.S.C. Section 638(j)(2) protect data generated under an SBIR award for 20 years from the date of award. During that period the federal government has limited rights, meaning the agency can use the data internally but cannot release it publicly or to third parties without your permission.
That said, writing "everything is protected, we share nothing" is not a compliant plan. The rest of this guide walks through how to write an NIH DMS Plan for SBIR that invokes the carve-out correctly, commits to the right level of sharing, and avoids the traps that trigger a Program Officer to kick the plan back.
What the NIH Data Management and Sharing Policy Actually Requires
The NIH Data Management and Sharing Policy took effect on January 25, 2023. It applies to every NIH-funded research project that generates scientific data, including SBIR and STTR awards.
Extractable answer: The NIH DMS Policy requires every funded project to submit a two-page Data Management and Sharing Plan describing what scientific data you will generate, how you will preserve and share it, when, where, and any justified limitations. The plan is reviewed by the Program Officer, not the study section, and does not affect your peer review score. For SBIR applicants, the SBIR data sharing requirements interact with, but do not override, the DMS Policy.
A few things founders get wrong about SBIR data sharing requirements:
The DMS Plan does not affect your peer review score. The Program Officer reviews it before award, not the study section. A weak plan will not lower your 1-9 scores, but it can delay award or trigger conditions.
"Scientific data" is narrower than you think. NIH defines it as data needed to validate and replicate findings. Not every intermediate artifact or log file. Not your source code unless the code itself is a research product.
Data sharing costs are allowable budget items. Repository fees, preservation, staff time to document the dataset. For a Phase I, a line of a few hundred to a few thousand dollars is common, depending on the repository and data volume.
You do not have to share raw data. You have to share what is needed to validate your published findings. That distinction is where SBIR Data Rights come in.
The SBIR Data Rights Carve-Out: What the Small Business Act Actually Says
The statutory basis is 15 U.S.C. Section 638(j)(2), which directs the SBA to implement a data rights framework for SBIR and STTR awardees. The operational details live in the SBIR Policy Directive.
Extractable answer: The SBIR Data Rights carve-out protects SBIR-generated data for 20 years from the date of award under 15 U.S.C. Section 638(j)(2). During this window the federal government holds "limited rights," meaning it can use the data for internal federal purposes but cannot release it outside the government or to third parties without written permission from the awardee. Coverage includes technical data, computer software, and source code generated during performance of the SBIR-funded work.
Key facts:
- The protection period is 20 years from the date of award. This was extended from four years by the SBIR Reauthorization Act of 2011.
- During the protection period, the federal government has "limited rights" to the data. The government can use the data for internal federal purposes, but cannot release it outside the government or to third parties without written permission from the awardee.
- The protection applies to "SBIR data," which generally means data generated during performance of the SBIR-funded work, including technical data, computer software, and source code.
- After 20 years, the government obtains unlimited rights.
Congress created this because small businesses need runway to commercialize before the government forces public release. The 20-year window is long enough to commercialize, file patents, raise follow-on capital, and establish market position.
SBIR Data Rights apply from the date of award, covering Phase I work. You do not need to be in Phase II to invoke them. The protection travels with the data through the full 20 years regardless of phase.
How SBIR Data Rights Interact with the NIH DMS Policy
NIH has addressed this interaction directly in its DMS Policy guidance, including NOT-OD-22-189 (the primary policy notice) and NOT-OD-22-213 (supplemental guidance on justified limitations). The DMS Plan template includes a section called "Access, Distribution, or Reuse Considerations" where applicants can describe justifiable limitations on data sharing. This is where SBIR Data Rights belong.
The NIH expectation is straightforward: every applicant must submit a plan, and every plan must commit to some level of sharing, but plans can describe legal, ethical, or technical reasons why certain data categories are restricted.
SBIR Data Rights are a legal basis that NIH accepts. You cite the statute, identify which data categories are covered, and then describe what you will share despite the protection.
A compliant SBIR DMS Plan looks like this:
- Cite the legal basis: 15 U.S.C. Section 638(j)(2) and the SBIR Policy Directive.
- Identify which data categories fall under SBIR Data Rights (training data, proprietary algorithms, biological assets, engineering specifications, whatever applies).
- Describe what you will share anyway: published results, aggregate metrics, de-identified validation subsets, metadata, methods documentation.
- Commit to a timeline and repository for the data you are sharing.
- State the 20-year protection window explicitly, with the start date tied to the award date.
Plans that stop at step 2 fail. Plans that skip step 2 overclaim. Plans that do all five pass.
How to Write an NIH Data Sharing Plan for SBIR Applicants
The NIH DMS Plan template has six required elements. Here is how to handle each one when you have proprietary data.
Element 1: Data Type
Describe the scientific data you will generate. For AI/ML, typically model predictions, performance metrics, held-out test results, benchmarking data. For biotech, experimental results, assay readouts, aggregate measurements.
Do not list every raw file or log. NIH is asking about data that validates findings.
If you have proprietary training data or biological materials, mention them briefly and note SBIR Data Rights coverage. Save detailed limitation language for Element 5.
Element 2: Related Tools, Software, Code
Disclose custom tools or software required to reuse the data. If the tool is your proprietary product, state that it is covered under SBIR Data Rights and will not be released, but data formats and APIs needed to work with published data will be documented.
Element 3: Standards
Identify data standards. For NIH research this often means common file formats (FASTQ, DICOM, CSV, JSON) and metadata schemas (FAIR principles, domain ontologies). Even when raw data is protected, the published subset should follow community standards.
Element 4: Data Preservation, Access, and Timelines
Where will the shareable data live, how long preserved, when shared?
Typical answer: shareable data goes to a public repository (Zenodo, Figshare, or a domain repository like GEO or ClinicalTrials.gov) at publication. Preservation for at least 10 years. Data covered by SBIR Data Rights is retained internally with access controls for the 20-year protection period.
Element 5: Access, Distribution, or Reuse Considerations
This is where you invoke the carve-out. Suggested structure:
Data generated under this award is subject to SBIR Data Rights under 15 U.S.C. Section 638(j)(2) and the SBIR Policy Directive. The following categories are designated SBIR data and are protected for 20 years from the date of award: [list categories]. During the protection period, the federal government has limited rights as defined in the SBIR Policy Directive. The following data will be shared publicly despite the protection: [list shareable data]. Requests for access to protected data during the protection period may be directed to [company contact] and will be evaluated on a case-by-case basis subject to appropriate data use agreements.
Element 6: Oversight of Data Management
Name the person responsible for data management (usually the PI or a designated Data Custodian at the company). Describe internal policies for data quality, security, and the process for evaluating external data requests.
Two pages total. Most SBIR applicants need about 1.5 pages of content.
Four Founder Scenarios and How to Handle Each
The following examples use fictional illustrative companies. None of these are real clients.
Scenario 1: AI/ML Company With Proprietary Training Data
A hypothetical company called NeuroSight AI trains a diagnostic model on 50,000 retinal images licensed under NDA. Model weights and training corpus are the core asset.
Plan: Invoke SBIR Data Rights on the training corpus and model weights. Share held-out test set performance (AUROC, sensitivity, specificity by subgroup), benchmark comparisons, and a de-identified sample sufficient to characterize the data. Deposit shareable outputs in Figshare at publication. Publish evaluation code, withhold training code.
Scenario 2: Biotech With Proprietary Cell Line or Antibody
A hypothetical company called Veritas Therapeutics has developed a humanized monoclonal antibody against a novel target. Sequence and production cell line are their IP.
Plan: Invoke SBIR Data Rights on the antibody sequence, cell line, and production protocols. Share binding affinity data, cytotoxicity results, in vivo efficacy curves, and published methods. Deposit standard assay data in an appropriate repository. Handle antibody requests through material transfer agreements.
Scenario 3: Digital Health Company With Patient-Derived Datasets
A hypothetical company called CardiaStream has a wearable-derived dataset of 10,000 patients with labeled arrhythmia events, combining proprietary signal processing with licensed patient data under BAAs.
Plan: Stack multiple protections: SBIR Data Rights on signal processing outputs, HIPAA on patient-identifiable elements, and human subjects privacy on raw recordings. Share fully de-identified aggregate statistics, model performance on a public benchmark, and publication-level data. Document the three-layer protection in Element 5 rather than relying on SBIR Data Rights alone.
Scenario 4: Hardware or Device Company
A hypothetical company called PhotonProbe is developing a fluorescence imaging probe. Core IP is an optical design and firmware.
Plan: Most experimental data can be shared freely. Invoke SBIR Data Rights only on the optical design files, firmware source, and any proprietary calibration routines. Share device performance data, protocols, and measurements in public repositories.
The principle across all four: invoke the carve-out on what is genuinely proprietary, share what you can without competitive harm. Overclaiming gets pushback. Underclaiming gives away your moat.
Common Mistakes Founders Make with DMS Plans
Mistake 1: Not writing a plan because "we don't generate data." Almost every NIH-funded project generates scientific data. If a Specific Aim produces results, you generate scientific data. Claiming otherwise is a red flag at pre-award.
Mistake 2: Overclaiming the carve-out. A plan that claims everything is protected with no sharing commitments will bounce. Program Officers know SBIR Data Rights do not excuse you from sharing published findings.
Mistake 3: Underclaiming. Some founders commit to open-data sharing of their training corpus or cell line because the first DMS template they found online was written for academic researchers. University library guides are a poor starting point for for-profit SBIR applicants.
Mistake 4: Treating the DMS Plan as a last-minute task. It interacts with your Research Strategy, Budget, and Commercialization Plan. Write it alongside those documents, not at 2 AM the night before submission.
Mistake 5: Copying another SBIR applicant's plan without adjusting scope. SBIR Data Rights scope depends on what counts as SBIR data in your specific project. A diagnostics company's plan will not fit a software company's situation.
The Bridge from Knowing to Doing
You now know more about NIH data sharing for SBIR than most grant writers. The 20-year carve-out exists, it is usable, and with the right template language it makes the DMS Plan a non-issue for proprietary-data companies.
Drafting the plan correctly is still work. The template has to match your Research Strategy. Sharing commitments have to align with your Budget line items. The Data Rights scope has to match what you consider proprietary, not more and not less.
If you want help writing a Phase I application where the DMS Plan is drafted with SBIR Data Rights applied, integrated with the Research Strategy, and checked against the Commercialization Plan's IP strategy, that is what Cada does. We have written 100+ grant proposals across 30+ federal agencies.
The first step is a 15-minute NIH SBIR readiness call. We tell you whether your company is competitive for the program you are targeting, before you invest 40 to 80 hours writing. No pitch, no obligation.
If you just want the template language, we have an NIH data sharing plan SBIR template with SBIR Data Rights built in. Email us and we will send it.
Either way, do not let the DMS Policy scare you off applying. The carve-out is real.