NIH GDSP Details

NIH recently made significant updates to the data security requirements (“Updated Requirements”) for researchers who want to access controlled-access human genomic data stored in NIH controlled-access data repositories (“Covered Data”) such as dbGaP and for individuals who assist in building the tools, platforms, and interfaces that are used to develop, manage, and maintain the NIH controlled-access repositories listed here (“Developers”).

Implementation Update for Data Management and Access Practices Under the Genomic Data Sharing Policy
Notice Number:  NOT-OD-24-157

The National Institutes of Health (NIH) is updating two practices under the NIH Genomic Data Sharing

(GDS) Policy to continue to promote responsible data management and access. These changes are to ensure GDS Policy implementation continues to evolve alongside changing practices for collecting, sharing, and using controlled-access human genomic data and include:

(1)   Modernizing security standards provided in the “NIH Security Best Practices for Controlled-Access Data Subject to the NIH Genomic Data Sharing (GDS) Policy”

and

(2)   Establishing minimum expectations for access to controlled-access data by developers. 

This update applies to all NIH funding mechanisms (grants, cooperative agreements, contracts, Other

Transactions, and intramural support) regardless of the activity code, that support the following activities:

  • Approved Users of controlled-access human genomic data from NIH controlled-access data repositories.
  • NIH controlled-access data repositories and access systems that meet the following criteria:
    • Are supported by a NIH grant, cooperative agreement, Other Transaction, contract, or intramural support;
    • Provide long-term storage for, or control access to, human genomic data generated and shared under the GDS Policy;
    • Control access to human genomic data by prospective review of data access requests or partner with access systems that control access via prospective review of requests; and
    • Use federal employees to conduct reviews and authorize access, or partner with access systems that use federal employees for those purposes.
  • Developers who test platforms, pipelines, analysis tools, and user interfaces that store, manage, and interact with human genomic data from NIH controlled-access data repositories as well as provide infrastructure development and repository maintenance.

Note:  NIH will treat cloud workspaces meeting the above criteria as controlled-access data repositories subject to the relevant expectations under this update. 

Note:  NIH does not intend to include in the definition of controlled access data repositories activities such as consortia data coordinating centers or similar activities that do not share data outside of a specific program or initiative.

The effective date of this update is January 25, 2025, including for the following mechanisms if they support activities described in the Scope and Applicability:

  • Competing grant applications (new and competing continuation) that are submitted to NIH on or after January 25, 2025, and subsequent receipt dates;
  • Proposals for contracts that are submitted to NIH on or after January 25, 2025;
  • Competing other funding agreements (e.g., Other Transactions) that are executed on or after January 25, 2025, unless otherwise stipulated by NIH; and
  • Continuing grants, cooperative agreements, contracts, and Other Transaction Awards ongoing as of January 25, 2025.

For competing awards that support NIH controlled-access data repositories and access systems or developers as described in the Scope and Applicability of this Notice, NIH Institutes, Centers, and Offices (ICOs) are expected to include the applicable implementation update described in this Notice in the Notice of Funding Opportunity (NOFO). When awarded, compliance with the applicable implementation update will be included in the Term and Condition of Award.

For non-competing continuing awards that support NIH controlled-access data repositories and access systems or developers described in the Scope and Applicability of this Notice, the recipient will work with their funding NIH ICO to update their existing Term and Condition of Award to reflect the applicable implementation update described in this Notice as soon as possible, but no later than the next budget period following the effective date.

Updates for NIH Controlled-Access Data Repositories, Approved Users, and Developers

The “NIH Security Best Practices for Users of Controlled-Access Data” is intended to ensure that Approved Users of NIH controlled-access data under the GDS Policy maintain such data on institutional IT systems and third-party computing infrastructures that meet certain standards in accordance to NIST SP 800-171 “Protecting Controlled Unclassified Information in Nonfederal Information Systems and Organizations”. To that end, NIH expects that:

  • Approved Users of NIH controlled-access data will attest to NIH that their institution is compliant with NIST SP 800-171.
  • Approved Users choosing a third-party IT system and/or Cloud Service Provider (CSP) for data analysis and/or storage will provide NIH with an attestation affirming that the third-party system is compliant with NIST SP 800-171.

The process for submitting an attestation will vary and may be incorporated as part of the process for accessing controlled data or through other agreements. 

Update to Approved User Agreements

The “NIH Security Best Practices for Users of Controlled-Access Data” update will be effective on January 25, 2025, at which point adherence to this standard will be included in new or renewed Data Use Certifications or similar agreements stipulating terms of access to controlled-access human genomic data regardless of whether the Approved User is supported by NIH or not.

The NIH Security Best Practices for Controlled-Access Data Repositories

NIH controlled-access data repositories that provide access to controlled-access human genomic data under the GDS Policy or store such data on a long-term basis are obligated to protect the confidentiality, integrity, and availability of the data. Accordingly, NIH adopted security controls in accordance with NIST SP 800-53 “Security and Privacy Controls for Information Systems and Organizations”. To that end, the “NIH Security Best Practices for Controlled-Access Data Repositories” expects that NIH controlled-access data repositories that store and share human genomic data under the GDS Policy will:

  • Adopt NIST SP 800-53 Moderate baseline. 
    • Compliance with FedRAMP Moderate or FISMA Moderate satisfies the implementation of NIST SP 800-53 Moderate baseline controls.
  • If choosing to use a third-party IT system and/or CSP for storage and sharing, provide NIH with an attestation that the third-party IT system and/or CSP is compliant with NIST SP 800-53 Moderate baseline. 
    • Compliance with FedRAMP Moderate or FISMA Moderate satisfies the implementation of NIST SP 800-53 Moderate baseline controls.

Minimum Standard Operating Procedures for Developer Oversight

Developer work includes testing platforms, pipelines, analysis tools, and user interfaces that store, manage, and interact with human genomic data from NIH controlled-access data repositories, as well as providing infrastructure development and repository maintenance but does not include research (e.g., methods development). 

The Lead Developer(s) (e.g., for extramural the Principal Investigator (PI) who is listed as the Project Director (PD) or PI on the funding application); those that they directly supervise, and the Lead Developer’s institution are expected to agree to developer terms of access described in the Term and Condition of Award, the Developer Data Use Agreement, if applicable, and any additional NIH program or ICO specific requirements.

Developer access to controlled-access data will be overseen by the NIH Developer Data Access Committee (Developer DAC), who will review and approve requests for developer access based on the description of use provided via a Developer Use Statement (DUS)

Lead Developers seeking access are expected to submit a request containing a DUS to the NIH Developer DAC (DeveloperAccessDAC@od.nih.gov) no later than at Just-in-Time (JIT) for grants and cooperative agreements, with the proposal provided by the offeror for contracts, or with the application for funding with Other Transactions. If a project has multiple Lead Developers, (e.g., for multicomponent awards), each Lead Developer must submit a DUS. All Lead Developers must be associated with an institution that is receiving or applying for NIH or other federal support for the developer work with a funding mechanism that has incorporated the developer terms of access.

The DUS should contain at least the following (note that NIH ICOs may have additional expectations):

A justification of why developer access is needed and intended developer activities.

If a Lead Developer is managing a repository (e.g., performing activities such as repository maintenance and infrastructure development), an attestation that the Lead Developer will adhere to the “NIH Security Best Practices for Controlled-Access Data Repositories” and list the standard being implemented.

If a Lead Developer is not managing a repository (e.g., not performing activities such as repository maintenance or infrastructure development), an attestation that the Lead Developer will adhere to the “NIH Security Best Practices for Users of Controlled-Access Data” and list the standard being implemented.

If the Lead Developer is using a third-party IT system and/or CSP, the Lead Developer will list the name and provide an attestation to NIH that the third-party IT system and/or CSP is compliant with the "Security Best Practices" attested to by the Lead Developer and list the standard being implemented.

Acknowledgment that the Lead Developer’s institution, the Lead Developer and those that they directly supervise will adhere to the developer terms of access and any additional NIH program or ICO-specific requirements for NIH-controlled access and have reviewed role-based training on the NIH Security Awareness Course.

If the Lead Developer works with a developer partner that requires access to controlled-access data, list the name of the developer partner’s institution and developer partner program manager. See below for additional details about developer partners.

If the Lead Developer seeks to work with a partner not directly funded by NIH or the federal government that will need access to NIH controlled-access data (and is not a third-party IT system and/or CSP) NIH will only provide the developer partner access to controlled-access data if:

  • Both the Lead Developer and developer partner enter into a contract containing the terms of developer access in the Term and Condition of the Award (or Developer Data Use Agreement, if applicable).
  • The Lead Developer identifies the developer partner institution and developer partner program manager in their DUS and submits it to the NIH Developer DAC and is approved. For ongoing developer work, the Lead Developer can revise and resubmit the DUS.
  • The developer partner submits a DUS to the NIH Developer DAC for review that lists the name of the developer partner’s institution, developer partner program manager, and IT Director and, if approved, the developer partner and their Institutional Signing Official co-sign the Developer Data Use Agreement and any additional NIH program or ICO-specific requirements.

COGR Additional Information

The NIH clarified that the developer terms of access will apply only when individuals are conducting “Developer Activities,” on a federally funded research project that “relate to developing or maintaining an NIH controlled-access data repository” listed here

NIH provided additional information that clarifies the scope of the activities it considers to be “research,” which is not subject to the developer terms of access. 

  • The Notices state that “methods development” constitutes research that is exempt from the developer terms of access. 
    • NIH stated that “methods development” includes researcher’s development of tools that are unrelated to developing or maintaining NIH controlled-access data repositories.
  • Accordingly, a researcher’s use of controlled-access data from an NIH controlled-access repository to develop a novel tool that the researcher will use in their own research does not constitute a Developer Activity unless the work was funded by NIH (or another federal agency) for the specific purpose of being incorporated into an NIH controlled-access repository. 

NIH will Specify When the Developer Terms of Access Apply in Funding Instruments: Going forward, any applicable Notice of Funding Opportunity (NOFO), contract, or Other Transaction supporting Developer Activities will indicate the applicability of the Notices and the developer terms of access to ensure awardees understand when the developer access terms apply. 

NIH states in the GDS FAQs that to be considered in compliance, at a minimum, institutions must:

  • “Assess their security posture” against NIST SP 800-171 (or equivalent standards at ISO/IEC 27001/27001) to identify gaps where additional risk mitigation is needed. 
  • Develop a Plan of Action and Milestones (POAM) to address identified areas where additional risk mitigation is needed. In developing this POAM, institutions should refer to NIST 800-171, §03.11.04 for “information on how to manage the risk of partially implemented or planned security controls.