# Data Sharing Plan Compliance Checklist: A Step-by-Step Audit By the end of this article you will be able to audit any [data management](/blog/guides/data-management-basics-principles-processes-and-best-practices) and sharing plan (DMSP) against its funder's requirements, calculate a numerical compliance score for that plan, identify the specific elements and sub-elements that are missing, and produce a corrected plan plus a reviewer-ready data package. You will need three things on hand: the plan document itself, the funder's policy or template (for example the NIH Data Management and Sharing Plan format page for NIH-funded work), and either a spreadsheet program or Python 3 installed on your computer. This audit method exists because most plans fail in predictable ways. A survey of 155 researchers at an academic medical center found that while 67% understood the NIH Data Management and Sharing (DMS) Policy, only 47% felt comfortable writing a plan, only 29% had used the DMPTool planning application, and confidence dropped sharply for two specific tasks: identifying an appropriate repository (40% confident) and budgeting for data sharing activities (38% confident) [1]. A checklist audit targets exactly those failure points. ## Why Audit a Data Sharing Plan Before Submission A data sharing plan is a short document submitted with a grant application that describes what data the project will generate, how the data will be curated and documented, where the data will be deposited, when the data will become accessible, and who oversees the process. Under the NIH DMS Policy (NOT-OD-21-013), every NIH-funded project that generates scientific data must include one [2]. Funders generally do not reject plans at review, but they do send comments during the Just-in-Time period when the plan is incomplete, and those comments create rework. When one academic medical center monitored 18 months of NIH submissions, it found that unstructured, free-form plans consistently underperformed structured templates on completeness, and that reviewer comments clustered on the same weak elements [2]. An audit with a checklist before you submit catches those problems while they are still cheap to fix. The audit also matters after the award. Surveys of top clinical trial sponsors operating in Europe found wide variation in whether organizations publish data sharing policies, provide plan templates, and use data use agreements, which means a research team working across sponsors cannot assume one plan fits every funder [3]. Auditing against each funder's specific language prevents that mismatch. ## The Compliance Checklist Formula The core of any data sharing plan compliance checklist is a scoring rule applied to a fixed list of required elements. The most widely used form is binary and follows the rubric approach used in institutional DMSP reviews, where each required element and sub-element is marked as either addressed or not addressed [2]. **Basic compliance formula:** ``` Compliance % = (number of required elements addressed / total required elements) × 100 ``` **Weighted compliance formula** (used when some elements matter more than others): ``` Weighted compliance % = (Σ element score × element weight) / (Σ maximum score × weight) × 100 ``` For a graded audit, score each element on a 0 to 2 scale: - **0** = element absent or contradicted elsewhere in the plan - **1** = element mentioned but incomplete (for example, a repository is named with no deposit timeline) - **2** = element fully addressed with a specific, verifiable statement The graded scale is more informative than the binary one because element-level compliance in real submissions varies widely. In the institutional study cited above, overall element compliance ranged from 98.9% for the data type element down to 82.7% for the tools and software element, and at the sub-element level the spread was even wider, from 98.9% for data description down to 49.3% for data generation [2]. A binary pass/fail would hide that the tools and data generation sections were the weak spots. | Item | Basic (binary) | Graded (0 to 2) | Weighted (0 to 2 × weights) | |--|--|--|--| | Question answered | Was each element addressed? | How completely? | How completely, weighted by risk? | | Formula | addressed ÷ required × 100 | Σ score ÷ (2 × n) × 100 | Σ(score × w) ÷ Σ(2 × w) × 100 | | Best for | Funder submission gate | Self-audit and revision | Multi-funder portfolios | | Limitation | Hides partial gaps | All elements count equally | Weights are judgment calls | ## The Checklist: Six Elements and Their Sub-Elements For NIH-funded work, the plan must cover six required elements [2]. The checklist below lists each element and the sub-questions an auditor should ask. These questions mirror the sub-element structure that institutional rubrics use when scoring plans [2]. 1. **Data type.** What data will be generated? What data will be shared or not shared, and why? Is the data description concrete (sample counts, data formats, modalities)? 2. **Related tools, software, and code.** What software or code is needed to access or analyze the data? Is there a plan for sharing code, and is the software environment described well enough for someone else to reproduce results? 3. **Standards.** What data formats, metadata standards, and identifiers will be used? Are the named standards actually appropriate for the data types listed? 4. **Data preservation, access, and timelines.** Where will data be deposited (named repository or archive)? When will data be available, and are there access restrictions or a controlled-access process described? 5. **Data management and oversight.** Who is responsible for data management at each stage? Are roles named rather than described generically? 6. **Budget.** Are costs for curating, documenting, and depositing data estimated, and is it clear whether these costs are requested in the budget or absorbed by the institution? Two of these deserve extra audit time. The repository question is where researchers report the least confidence, with only 40% confident in identifying an appropriate repository in one institutional survey [1]. The budget question is close behind at 38% confidence [1]. If your plan names a repository and a dollar figure with a justification, you have handled the two weakest elements in the average submission. ## Step-by-Step Audit Walkthrough Work through the following steps with your plan open and the funder template open beside it. The walkthrough uses the NIH six-element structure, but the same procedure works for any funder's template once you substitute that funder's element list. ### Step 1: Build the scoring sheet Create a spreadsheet or text file with one row per required element and sub-element. For a quick start, save the following as `dmsp_elements.csv`: ```csv element,sub_element,weight data_type,data description,1 data_type,data to be shared or not shared and rationale,1 tools_software,software and code needed to interpret data,2 tools_software,special or proprietary software access,2 standards,formats and metadata standards,1 standards,versioning and identifiers,1 preservation_access,repository named,2 preservation_access,deposit and access timeline,2 preservation_access,restrictions and access controls,1 oversight,named responsible roles,1 budget,cost estimate and justification,2 ``` The weights reflect the two findings that matter most for audit risk: repository choice and budget are the tasks researchers report the least confidence in [1], and tools and software was the weakest element in measured submissions [2]. ### Step 2: Read the plan against one element at a time Read the plan looking only for evidence of the first element, then the second, and so on. Do not read straight through marking as you go. Reading one element at a time is the same discipline used in multi-center plan comparison studies, where independent review of each requirement against defined criteria is what makes scores comparable across reviewers [4]. For each sub-element, assign 0, 1, or 2 and write the sentence in the plan that justifies the score. If you cannot point to a specific sentence, the score is 0. This is the single rule that keeps audits honest. ### Step 3: Calculate the compliance score ![Calculation card showing the weighted compliance formula applied to the article's 11 scored sub-elements, giving 60.0 percent.](/article-images/illustrations/data-sharing-plan-compliance-checklist-weighted-score-worked.webp) Save your scores in `dmsp_scores.csv`: ```csv sub_element,score data description,2 data to be shared or not shared and rationale,2 software and code needed to interpret data,1 special or proprietary software access,0 formats and metadata standards,2 versioning and identifiers,1 repository named,2 deposit and access timeline,1 restrictions and access controls,1 named responsible roles,2 cost estimate and justification,0 ``` Then run this script, saved as `dmsp_checker.py`: ```python import csv def load_scores(path): with open(path, newline="") as f: return {r["sub_element"]: int(r["score"]) for r in csv.DictReader(f)} def load_weights(path): with open(path, newline="") as f: return {r["sub_element"]: int(r["weight"]) for r in csv.DictReader(f)} def audit(scores, weights): n = len(scores) binary_pass = sum(1 for s in scores.values() if s > 0) binary_pct = binary_pass / n * 100 graded_pct = sum(scores.values()) / (2 * n) * 100 weighted_pct = (sum(scores[k] * weights[k] for k in scores) / sum(2 * weights[k] for k in scores)) * 100 print(f"Sub-elements scored: {n}") print(f"Binary compliance: {binary_pass}/{n} = {binary_pct:.1f}%") print(f"Graded compliance: {graded_pct:.1f}%") print(f"Weighted compliance: {weighted_pct:.1f}%") print("Weakest sub-elements (score 0 or 1):") for k, v in sorted(scores.items(), key=lambda x: x[1]): if v < 2: print(f" score {v}: {k}") scores = load_scores("dmsp_scores.csv") weights = load_weights("dmsp_weights_from_elements.csv") audit(scores, weights) ``` Run it: ```bash python dmsp_checker.py ``` **Expected output:** ``` Sub-elements scored: 11 Binary compliance: 10/11 = 90.9% Graded compliance: 68.2% Weighted compliance: 60.0% Weakest sub-elements (score 0 or 1): score 0: special or proprietary software access score 0: cost estimate and justification score 1: software and code needed to interpret data score 1: versioning and identifiers score 1: deposit and access timeline score 1: restrictions and access controls ``` This worked example shows why the data sharing plan compliance checklist formula you choose changes the picture. The binary score says 90.9%, which sounds ready to submit. The weighted score says 60.0%, because the two zero-scored sub-elements carry double weight and both are known weak points across real submissions [2]. For submission decisions, use the weighted score and the sub-element list together. ### Step 4: Fix the zeros first, then the ones ![Decision path for a failed audit: fix zero-scored sub-elements first, then ones, then re-audit against the threshold.](/article-images/illustrations/data-sharing-plan-compliance-checklist-fix-order-triage.webp) Every zero is a missing commitment. In the worked example, the plan never says how proprietary software access will be handled and never estimates costs. Fix these with concrete sentences, for example: "Deposition to [named repository] will occur within 90 days of publication, or at the end of the award period, whichever comes first." Vague sentences such as "data will be made available to the extent possible" should be rewritten or they will earn a score of 1 again on re-audit. ### Step 5: Re-audit and check the result Re-run the checker after revision. A plan is audit-ready when the weighted score is at or above your institution's threshold and no sub-element scores 0. Institutional experience shows what is achievable: 79.3% of submitted plans in one 18-month review addressed all required elements, and structured templates pushed completeness higher than free-form writing [2]. If your first audit lands below 80%, using a structured template rather than editing free-form text is the evidence-supported fix [2]. ### Step 6: Verify the deliverable, not just the plan A compliant plan describes a data package that a stranger could actually use. Audit the plan's promises against a concrete model. The FOCUS4 colorectal cancer trial, which recruited 1,434 patients across 94 UK sites, released a Data Pack containing pseudonymized registration and follow-up data, marked case report forms, a data dictionary, the study protocol, and the statistical analysis plan, organized so that external researchers could replicate or extend analyses [5]. Your plan's repository deposit should map to that same inventory: data files, a data dictionary, the protocol or analysis documents needed to interpret the data, and clear de-identification status. ## Choosing Where to Deposit: A Data Repository Comparison The audit almost always stalls at the repository line. Use three criteria to compare options, and record the comparison in the plan itself so reviewers see the reasoning. 1. **Scope fit.** A discipline-specific repository accepted by your community is preferred under the NIH DMS Policy when one exists, with a generalist repository as the fallback. This is an explicit rule of the policy, and it is also the question researchers report the least confidence answering [1]. Search the funder's list of recommended repositories before defaulting to a generalist option. 2. **Access model and restrictions.** For sensitive or human-subjects data, the plan must name the access controls the repository provides and who approves data requests. Uncertainty about handling sensitive data was one of the implementation challenges researchers reported in institutional surveys [1]. 3. **Curation and persistence.** A repository that assigns persistent identifiers, curates metadata against a standard, and commits to long-term preservation scores higher than a passive file store. The curation difference is what turns a deposit into a usable package like the FOCUS4 Data Pack, which paired data files with a data dictionary and protocol documents [5]. A practical comparison table in your plan might look like this: | Criterion | Discipline-specific repository | Generalist repository | Institutional repository | |--|--|--|--| | Scope fit for your data type | High if listed by funder | Moderate | Variable | | Access controls for sensitive data | Usually built in | Varies by repository | Varies by institution | | Metadata curation | Community standards enforced | Generic metadata | Local standards | | Preservation commitment | Typically long term | Varies | Tied to institutional policy | Score each candidate against the three criteria, pick the top option, and name it explicitly in the preservation and access element. "An appropriate public repository" is an automatic score of 1 in any audit. ## Common Mistakes and Limitations - **Scoring from memory instead of from the text.** Every nonzero score must be tied to a sentence in the plan. If you cannot quote it, score 0. - **Auditing only the six element headings.** Sub-elements fail more often than elements. In measured submissions, the data type element scored 98.9% while one of its own sub-elements, data generation, scored only 49.3% [2]. An element-level audit would have missed that. - **Writing free-form and hoping.** Unstructured plans consistently underperform structured templates on completeness in institutional implementation data [2]. Start from the funder's template or DMPTool, both of which researchers in one survey said they wanted more of (87% requested tailored templates) [1]. - **Ignoring the budget element.** Budget was one of the two lowest-confidence tasks in the researcher survey at 38%, and it is a required element, not an optional extra [1]. - **Treating the audit as one-time.** Plans drift from practice during a project. The sustainment lesson from operational compliance monitoring is that performance decays without periodic re-measurement and feedback, and that relaunching a structured monitoring cycle restores gains that eroded over time [6]. Re-audit annually or at each renewal. - **Assuming one plan satisfies all sponsors.** Sponsor-level requirements for policies, plans, and data use agreements vary substantially, so a multi-sponsored program needs a per-sponsor audit, not a single master checklist [3]. - **A general caution about score thresholds.** The percentages in this article describe reported study populations, not guarantees. Whether a given funder accepts a plan depends on that funder's reviewers, and any plan for human-subjects data needs review by your institution's compliance office or IRB before deposition. ## Frequently Asked Questions ### What is a data sharing plan compliance checklist? It is a fixed list of the elements and sub-elements a funder requires in a data management and sharing plan, together with scoring rules for judging whether each one is addressed. You apply it to a draft plan to find gaps before submission. ### How do I calculate a data sharing plan compliance score? Count the required elements addressed and divide by the total required, then multiply by 100. For a graded audit, score each element 0 to 2 and divide the sum of scores by twice the number of elements, then multiply by 100. Both formulas appear in the table above. ### What score counts as passing? No universal passing threshold exists in funder policy. In one institutional review of real NIH submissions, 79.3% of plans addressed all required elements, so completeness at or above that level is a reasonable internal target [2]. ### What is a data sharing plan compliance checker? It is any tool that automates the checklist scoring. The `dmsp_checker.py` script in this article is a minimal example. Structured templates with built-in element fields, including NIH-provided and institutional templates, act as checkers during drafting by making omissions visible [2]. ### Which plan elements are most often incomplete? Tools and software was the weakest required element in measured submissions at 82.7% compliance, and data generation was the weakest sub-element at 49.3% [2]. Repository selection and budgeting are the tasks researchers report the least confidence in [1]. ### Do structured templates actually improve compliance? Yes. In a direct comparison at one academic medical center, structured DMSP templates outperformed unstructured, investigator-created plans on completeness and drew fewer reviewer comments [2]. ### How do I choose a repository for my data? Compare candidates on scope fit, access controls, and curation and preservation commitments, then name the chosen repository and the deposit timeline explicitly in the plan. Discipline-specific repositories listed by your funder take priority under the NIH policy [1]. ### What should a finished data package include? At minimum, the data files, a data dictionary, and the documents needed to interpret them. The FOCUS4 trial's Data Pack bundled pseudonymized data, marked case report forms, a data dictionary, the protocol, and the statistical analysis plan [5]. ## Sources 1. [Supporting researcher compliance: assessing institutional readiness for the 2023 NIH Data Management and Sharing Policy.](https://pubmed.ncbi.nlm.nih.gov/42889533/) 2. [Structured Data Management and Sharing Plan (DMSP) templates outperformed non-structured ones in an institutional implementation of the NIH Data Management and Sharing (DMS) policy.](https://pubmed.ncbi.nlm.nih.gov/41445711/) 3. [Data sharing policies, requirements, and support from public and private clinical trial sponsors: a survey on top sponsors of clinical trials in Europe.](https://pubmed.ncbi.nlm.nih.gov/42575483/) 4. [Dosimetric Multicenter Planning Comparison Studies for Stereotactic Body Radiation Therapy: Methodology and Future Perspectives.](https://pubmed.ncbi.nlm.nih.gov/31707124/) 5. [Facilitating access to clinical data from a randomized controlled trial of complex adaptive design.](https://pubmed.ncbi.nlm.nih.gov/42437936/) 6. [Relaunch of an electronic monitoring system to sustain hand hygiene observations and compliance: A quality improvement study.](https://pubmed.ncbi.nlm.nih.gov/40902858/)