Key Dates

Related Announcements

• November 30, 2021 - Request for Information on Proposed Updates and Long-Term Considerations for the NIH Genomic Data Sharing Policy. See Notice NOT-OD-22-029
• October 29, 2020 - Final NIH Policy for Data Management and Sharing. See Notice NOT-OD-21-013
• August 27, 2014 - NIH Genomic Data Sharing Policy See Notice NOT-OD-14-124 

Issued by

Office of The Director, National Institutes of Health (OD)

Purpose

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 implementation update will take effect on January 25, 2025.

Background

The NIH Genomic Data Sharing (GDS) Policy (NOT-OD-14-124) sets forth NIH’s expectations for the broad and responsible sharing of large-scale human and non-human genomic data. A core tenet of the GDS Policy is that research participants’ data will be provided and used only for purposes indicated by the submitting institution and overseen by NIH Data Access Committees (DACs). Importantly, those maintaining controlled-access data repositories, developing tools for sharing controlled access data, etc., –often referred to as “developers”– may also require access to these data. The GDS Policy is silent about this type of access by developers, and NIH has determined that a consistent minimum standard for developer access is needed as the number of controlled-access data repositories sharing genomic data under the GDS Policy increases. As such, NIH is providing additional clarity for developers to ensure data management and access practices align with the agency’s expectations under the GDS Policy.

Security standards are another critical component of upholding participant protections and ensuring the effectiveness of controls. Under the GDS Policy, NIH has relied on the “NIH Security Best Practices for Controlled-Access Data Subject to the NIH Genomic Data Sharing (GDS) Policy” to communicate security expectations for Approved Users and their institutions, and for repositories that store and share human genomic data. On November 30, 2021, NIH sought public feedback through a Request for Information, “Proposed Updates and Long-Term Considerations for the NIH GDS Policy” (NOT-OD-22-029), which requested feedback on whether controlled-access data repositories that store and share genomic data under the GDS Policy should have a FISMA and FedRAMP Moderate Authority to Operate (ATO).

Several respondents strongly supported expecting repositories to adopt FISMA and FedRAMP Moderate ATO controls. While no comments opposed the application of these standards, some respondents expressed concern that disparities in resource availability may limit some repositories and platforms from adopting certain security standards and protections. NIH understands that some burden may be imposed on institutions by expecting that they adopt the updated security standards and will monitor the impact of compliance. Respondents also suggested that FISMA and FedRAMP Moderate ATO protections may become inadequate as risks change, and that stronger protections may be needed in the future. NIH will continue to monitor risks and will update these standards as appropriate. Additionally, although NIH did not specifically request information on minimum standards for developer access, several respondents emphasized the importance of NIH controlled-access data repositories maintaining appropriate minimum standards and protections for data.

To update security expectations to reflect current standards and to standardize oversight approaches for developer access, NIH is implementing the following updates.

Scope and Applicability

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.

NIH will treat cloud workspaces meeting the above criteria as controlled-access data repositories subject to the relevant expectations under this update. 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.

Effective Date

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 INTRAMURAL ONLY: NIH intramural support including Intramural Research Projects (IRPs) conducted on or after January 25, 2025, and intramurally-funded NIH-managed data repositories established on or after that date; and continuing NIH intramural support ongoing as of January 25, 2025.

For competing awards (e.g., grants, contracts, cooperative agreements, and Other Transactions) 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 (e.g., grants, contracts, cooperative agreements, and Other Transactions) 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.

FOR INTRAMURAL ONLY: For new and ongoing IRP projects that support activities described in the Scope and Applicability of this Notice, the IRP project will work with their NIH ICO to adopt the applicable implementation update as soon as possible, but no later than the effective date of this notice. For newly established and ongoing intramurally-funded NIH-managed data repositories that support activities described in the Scope and Applicability of this Notice, the NIH-managed data repository will work with their managing NIH ICO to adopt the applicable implementation update as soon as possible, but no later than the effective date of this Notice.

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

The NIH Security Best Practices for Users of Controlled-Access Data

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.
• Non-U.S. users that are unable to attest to the NIST SP 800-171 may attest to the equivalent ISO/IEC 27001/27002 standard.

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.

Expectations under the NIH Security Best Practices for Users of Controlled-Access Data are in addition to, and do not supersede, any local, State, Tribal, Federal laws and regulations, and/or relevant institutional policies.

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 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, to 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 implementation of NIST SP 800-53 Moderate baseline controls.

Expectations under the NIH Security Best Practices for Controlled-Access Data Repositories are in addition to, and do not supersede, any local, State, Tribal, Federal laws and regulations, and/or relevant institutional policies.

Minimum Standard Operating Procedures for Developer Oversight

NIH is establishing a developer access framework to ensure that developers, and those they directly supervise, who are provided access to controlled-access human genomic data under the GDS Policy, maintain participant protections, privacy, and oversight consistent with Policy expectations. 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; for intramural the developer team lead at the managing NIH ICO repository), 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.

The developer terms of access are based on the terms of access for researchers under the GDS Policy and include provisions detailing developer responsibilities, agreement to public posting of the name of the Lead Developer’s institution, intended developer activities, prohibitions on re-identifying or recontacting participants, agreement to uphold NIH Certificates of Confidentiality, prohibitions on transferring data, adherence to the “NIH Security Best Practices for Controlled-Access Repositories” or, if applicable, the “NIH Security Best Practices for Users of Controlled-Access Data”, and review of the NIH Security Awareness Course, among other provisions. The Developer Code of Conduct, included in the terms of access, is based on the Genomic Data User Code of Conduct and the developer terms of access. Although this update is for developer access to human genomic data under the GDS Policy, it may be relevant to developer access to other data maintained in NIH controlled-access data repositories.

This Notice establishes minimum standard operating procedures for developer oversight; it does not create or standardize technical controls for intake, processing, or authorization of access requests. To that end, developer access to controlled-access data will be overseen by the NIH Developer Data Access Committee (Developer DAC), composed of federal employees with the appropriate subject matter expertise and/or program expertise who will review and approve requests for developer access based on the description of use provided via a Developer Use Statement (DUS) .Repositories may employ different mechanisms for providing and monitoring access to controlled-access data. They may also employ different mechanisms for different types of developers, e.g., for repository staff vs external application developers. Regardless of what technical controls repositories use to grant access, developer access is not granted until the NIH Developer DAC has approved.

Lead Developers seeking access are expected to submit a request containing a DUS to the NIH Developer DAC ([email protected]) 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.
• Acknowledgement 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 (https://irtsectraining.nih.gov/publicUser.aspx).
• 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.

Expectations under the Minimum Standard Operating Procedures for Developer Oversight are in addition to, and do not supersede, any local, State, Tribal, Federal laws and regulations, and/or relevant institutional policies. This framework, consisting of minimum standards for developer access, complements the NIST information security standards (e.g., NIST SP 800-53 and NIST SP 800-171) under the NIH Security Best Practices described in this Notice. It does not supersede, replace, or otherwise negate developer responsibilities under these standards.

Inquiries

Please direct all inquiries to:

IC Name: Office of Science Policy
Telephone: 301-496-9838
Email: [email protected]