The HITRUST CSF version 11 (v11) enables a fully traversable portfolio, which facilitates seamless movement between HITRUST assessments based on the use of common requirement statements to maximize reusability. As risk and compliance program maturity or information protection needs change, v11 allows organizations to use what they have already done to easily upgrade to higher levels of HITRUST assurance with just incremental effort. v11 enables cyber threat adaptive HITRUST Assessments across the portfolio that continuously evolve to address emerging threats such as ransomware and phishing.

The HITRUST CSF v11 framework includes new and refreshed Authoritative Sources powered by the speed and efficiency of Artificial Intelligence (AI). Plus, changes to Evaluative Elements and Illustrative Procedures that make it easier for MyCSF users to parse and score Requirement Statements.

v11 contains the following new and refreshed Authoritative Sources:

• Added NIST SP 800-53 revision 5 mapping and selectable Compliance factor
• Added Health Industry Cybersecurity Practices mapping and selectable Compliance factor
• Refreshed NIST SP 800-171 mapping
• Refreshed NIST Cybersecurity Framework mapping
• Refreshed HIPAA Security Rule, Privacy Rule, and Breach Notification mapping

For more details about HITRUST CSF v11, Refer to Advisory HAA 2023-001: CSF Version 11 Release.

For a comparison of the v9.6 i1 requirement statement to the v11.0 i1 requirement statements click here.

An authoritative source refresh is an update to a previously mapped authoritative source due to a change in the authoritative source or in order to refine the mapping using the NIST OLIR methodology.

Yes, v11 and v9.1 – 9.6 are currently accessible in MyCSF.
However, v9.1 – v9.4 are transitioning to an end-of-life process for r2 assessments and i1 assessments will transition for v9.6.2 to v11.

r2 Assessments

• On September 30, 2023, the ability to create new v9.1 – v9.4 r2 assessment objects in MyCSF is disabled.
• On December 31, 2024, the ability to submit v9.1 – v9.4 r2 assessment objects in MyCSF is disabled.
• On March 31, 2026, v9.1 – 9.4 libraries are removed from MyCSF.

v9.5 and v9.6 will continue to be available for r2 Assessments.

i1 Assessments

• Between January 18, 2023 and April 30, 2023, i1 assessments may created using either v9.6.2 or v11.
• On April 30, 2023, the ability to create new v9.6.2 i1 assessment objects in MyCSF is disabled.

On July 31, 2021, the ability to submit v9.6.2 and earlier i1 assessment objects in MyCSF is disabled.

There will be no impact to existing v9.1 – 9.6 r2 assessments in process unless an assessed entity chooses to upgrade an in-process assessment to v11. Note that existing v9.1 – 9.4 r2 assessments must be submitted to HITRUST by December 31, 2024.

In process i1 assessments using v9.6 or earlier must be submitted to HITRUST by July 31, 2023 or upgraded to v11 if not submitted by July 31, 2023.

Per the HITRUST Control Maturity Scoring Rubric, scoring a requirement statement requires locating and parsing the requirement’s evaluative elements. To make this task easier, HITRUST has moved the evaluative elements from the policy illustrative procedure to the requirement statement where they are individually numbered. This improves visibility of the evaluative elements without increasing the level of effort to evaluate each requirement statement.

For the vast majority of requirement statements, the evaluative elements did not change – they were simply moved from the illustrative procedures to the requirement statement. In less than 30 requirement statements, when the evaluative elements were relocated to the requirement statement, some evaluative elements were removed, added, or edited for clarity. The CSF Summary of Changes document contains the detailed changes.

For all requirement statements in the v11 library, the illustrative procedures have been updated as follows:

• Policy: Since the evaluative elements have been moved from the policy level illustrative procedures to the requirement statements, all policy level illustrative procedures have been updated to the following standard text:
  Examine policies related to each evaluative element within the requirement statement. Validate the existence of a written or undocumented policy as defined in the HITRUST Scoring Rubric.
• Process: All process level illustrative procedures have been updated to the following standard text:
  Examine evidence that written or undocumented procedures exist as defined in the HITRUST Scoring Rubric. Determine if the procedures address the operational aspects of how to perform each evaluative element within the requirement statement.
• Implemented: To enhance usability, the implemented level illustrative procedures have been reformatted:
  Examine evidence that all evaluative elements within the requirement statement have been implemented as defined in the HITRUST Scoring Rubric using a sample based test where indicated below in the example test. If a sample based test is not possible, provide justification to support an alternative testing approach.
  Example test(s):
  
• Measured: To enhance usability, the measured level illustrative procedures have been reformatted:
  Examine measurements that formally evaluate and communicate the operation and/or performance of each evaluative element within the requirement statement. Determine the percentage of evaluative elements addressed by the organization’s operational and/or independent measure(s) or metric(s) as defined in the HITRUST Scoring Rubric. Determine if the measurements include independent and/or operational measure(s) or metric(s) as defined in the HITRUST Scoring Rubric.
  Example test(s):
  
• Managed: All managed level illustrative procedures have been updated to the following standard text:
  Examine evidence that a written or undocumented risk treatment process exists, as defined in the HITRUST Scoring Rubric. Determine the frequency that the risk treatment process was applied to issues identified for each evaluative element within the requirement statement.

For v9.1 – 9.6, the evaluative elements have been numbered although they remain within the policy level illustrative procedure and have not been moved to the requirement statement.

MyCSF subscribers can utilize the preview functionality described in HAA 2021-006 to determine impact on an existing assessment prior to upgrading to v11 including a detailed look at the direct changes that will apply to the assessment.

See an example below of a requirement statement (BUID 1804.08b2Organizational.12) and the corresponding policy level illustrative procedure in v9.6.2 and v11.

v9.6.2

 

 
v11

 

When the HITRUST quarterly reconciliation of cyber threat intelligence to the HITRUST CSF requirements results in the need to update the core requirement selection, a new major or minor CSF version will be released. The previous CSF version will remain active for a period of time to provide time to transition to the new version. Based upon the quarterly reconciliations performed in
2022, HITRUST does not expect significant changes in the core requirement selection from one version to the next.

No, interim and bridge assessments will continue to use the same CSF version as their corresponding r2 assessments.

For the v11 r2 baseline, the level 1 requirements from the 75 controls required by certification have been replaced with the core requirement selection. The core requirement selection is made up of the i1 requirement statements.

For r2 assessments using v11, the assessment option “Would you like only the controls required for certification or ALL CSF security controls?” has been updated to “Will this be a comprehensive assessment?”. When answered yes, the tailoring of the r2 assessment based on factor responses will include requirement statements across all 135 security control references rather than only the 75 control references required for certification.

No, privacy controls may still be included using the assessment option “Include privacy controls?”.

Yes, a new major or minor CSF version will be released each time the core requirement selection changes.

No, the r2 assessment factors continue to work in v11 just as they do in v9.x.

No, the average v11 assessment is up to 9% smaller in requirement count compared to v9.x assessments (depending on the v9.x version used).

In general v11 assessments can inherit from v9.x assessments and vice versa. However, due to the change to the r2 assessment baseline, if an organization uses v9.x and their service provider uses v11, there may be requirement statements included in the v9.x assessment that are not present in the service provider’s v11 assessment and therefore would not be inheritable. To account for this, HITRUST has created a Community Supplemental Requirement factor that inheritance providers are encouraged to select to include additional inheritable 9.x requirement statements into v11 r2 Assessments.

The following 58 requirement statements are common between the v11 r2 core and v9.x r2 baseline:

 
The following 124 requirement statements are included in the v11 r2 core and are not included in the v9.x r2 baseline:
 

No. For v11, while the r2 assessment baseline has been updated, the process of tailoring of the assessment according to the factor responses has not changed.

The HITRUST CSF integrates and harmonizes information protection requirements from many authoritative sources – including ISO, NIST, PCI, and HIPPA, and tailors the requirements to an organization, based on specific organizational, system, and compliance risk factors. The level of integration and prescriptiveness provided by the framework, along with the quality and rigor of the HITRUST Assurance Program and supporting HITRUST products and services, make the HITRUST CSF the easy choice for organizations in any industry.

The decision to adopt the HITRUST CSF should be made at the organizational level; after which, the organization should perform an internal gap analysis of existing controls against the target controls in the HITRUST CSF. This analysis can be done manually or by utilizing HITRUST’s SaaS solution, MyCSF. Once the information protection posture of the organization is understood, a risk management strategy and implementation timeline can be developed and communicated throughout the organization

The latest version of the HITRUST CSF framework is available to download for FREE on the HITRUST website for qualified organizations. A qualified organization is defined as any organization employing a function or activity involving information protection, provided said organization does not offer security and/or privacy products or services. In addition, any federal, state, or local agency or department may be considered a qualified organization.

If you are not sure whether your organization is qualified, please contact sales@hitrustalliance.net or call 855-HITRUST. HITRUST has the right to verify eligibility.

Download the HITRUST CSF free of charge for qualified organizations.

The core structure of the HITRUST CSF is based on ISO/IEC 27001:2005 and 27002:2005, published by the International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC), and incorporates dozens of other security and privacy related regulations, standards, and frameworks providing comprehensive and prescriptive coverage.

The HITRUST CSF is structured along the lines of ISO 27001:2005 with the 11 control clauses (or categories); however, adds an additional control category to address implementation of an Information Security Management Program, similar to that of the ISMS of ISO 27001:2005, and another category to address risk management. HITRUST has also incorporated a 14th control category to address specific privacy practices, such as GDPR, that are otherwise not addressed in the previous 13 categories.

There are 156 security and privacy-related control specifications, with associated implementation requirements; of which, 21 specifically address privacy practices.

Because the HITRUST CSF is both risk- and compliance-based, organizations of varying risk profiles can customize the security and privacy control baselines through a variety of factors including an organization’s type, size, systems, regulatory, and compliance requirements.

The HITRUST CSF risk-based approach used in the HITRUST r2 Assessment applies security/privacy resources commensurate with the level of risk by defining multiple levels of implementation requirements – which increase in restrictiveness. Three levels of requirements are defined based on organizational and system risk factors. Level 1 provides the minimum baseline control requirements; each subsequent level encompasses the lower level and includes additional requirements, commensurate with increasing levels of risk.

To further tailor the control baseline in an r2, the compliance-based approach allows organizations to incorporate additional regulatory or compliance components which meet the organization’s needs and/or requirements.

The HITRUST CSF is an information protection standard which can be effectively used by organizations across any industry–not just healthcare. The HITRUST CSF provides a consensus-driven standard of due care and due diligence for the protection of information–including electronic protected health information (ePHI), personally identifiable information (PII), payment card data, proprietary information, or other sensitive information.

Yes, organizations outside of the U.S. have implemented the HITRUST CSF. Moreover, additional countries have expressed an interest in HITRUST, and we expect this interest to grow as adoption continues to increase within the U.S.

For more information, refer to Understanding and Leveraging the CSF webpage.

The simple answer is that there is no relationship between the HITRUST CSF control categories and the assessment domains. The HITRUST CSF control categories were derived from ISO and provide the structure for the framework. The assessment domains take the control requirements and group them into logical domains, based on common IT organizational structure. This is done to make performing an assessment more efficient as controls should be well-grouped around typical IT departments.