Updates to HITRUST®: Version 1.4.1 Shared Responsibility Matrix

What is the HITRUST Shared Responsibility and Inheritance Program?

The HITRUST Shared Responsibility and Inheritance Program streamlines the HITRUST certification journey and makes it easier and quicker to achieve security certification. With this program, organizations can now reuse previously certified controls. Suppose your organization partners with a Cloud Service Provider (CSP), and the CSP is responsible for operating a security control such as physical security or wireless access points. In that case, the Inheritance Program allows you, at the click of a mouse, to bring in the scoring from the CSP’s MyCSF object into your MyCSF object. This helps reduce the resources you must commit to during the rigorous validated assessment and makes the process much more efficient.  CSPs include but are not limited to Amazon (AWS), Microsoft (Azure), and Google (GCP). 

The HITRUST Shared Responsibility Matrix (SRM) is a free, easy-to-use baseline template that pre-populates shared responsibility and controls inheritability in shared cloud environments. Leading CSPs and their relying customers widely adopt the HITRUST SRM.

Details of the HITRUST Update

On August 17, 2023, HITRUST announced the update to version 1.4.1 HITRUST SRM. The CSPs’ SRMs have also all been updated to version 1.4.1 to reflect the change. The update aims to provide visibility into inheritance values on the evaluative elements (EE) level. This visibility allows assessed entities and assessors to make more informed decisions on the inheritance weights of each requirement statement (RS). For a more manageable transition from version 1.4 HITRUST Legacy SRM to version 1.4.1 HITRUST SRM, any assessed entity who submits an inheritance request before January 31, 2024, within MyCSF may use weights from either the version 1.4 HITRUST Legacy SRM or version 1.4.1 HITRUST SRM. Version 1.4.1 HITRUST SRM can be found in the References tab on the HITRUST MyCSF website. 

Key Takeaways

The Legacy SRM previously provided inheritance information on the requirement statement level. A requirement statement can be characterized as not inheritable, partially inheritable, or fully inheritable. The updated version 1.4.1 SRM clarifies how responsibility is divided since inheritability is no longer solely shown in the SRM on the requirement statement level but also on the evaluative elements level. Each requirement statement may have multiple evaluative elements; therefore, inheritance on the evaluative elements level gives a more detailed portrayal of the responsibilities between the CSP and the assessed entity.  

Example as follows: Example 1

Baseline Unique ID (BUID): 1101.01a1Organizational.1245

Cross-version ID (CVID): 0013.0

HITRUST CSF v11 Requirement Statement: Access control rules and rights for each user or group of users (1) are based on clearly defined requirements for information dissemination and authorization (e.g., need-to-know, need-to-share, least privilege, security levels, and information classification). Further, logical, and physical access control rules and rights for each user or group of users (2) are considered together and clearly defined in standard user access profiles (e.g., roles). The access control program (3) considers the security requirements of individual business applications and business units and ensures standard user access profiles for common job roles in the organization.

Requirement-level inheritability: Partially inheritable

Number of Evaluative Elements (EEs): 3, as follows:

• EE #1 (Not inheritable): The policy addresses access control rules and rights for each user or group of users based on clearly defined requirements for information dissemination and authorization (e.g., need-to-know, need-to-share, least privilege, security levels, and information classification).
• EE #2 (Fully inheritable): Further, logical, and physical access control rules and rights for each user or group of users are considered together and clearly defined in standard user access profiles (e.g., roles). 
• EE #3 (Not inheritable): The access control program considers security requirements of individual business applications and business units and ensures standard user access profiles for common job roles in the organization. 

When a requirement statement is partially inheritable (as is the case in this example), the inheriting organization is not able to completely inherit the requirement statement’s scoring from a service provider such as a CSP. Instead, they must evaluate and score at least a portion of the requirement statement’s local performance. Now that inheritability is shown at the evaluative element level in the updated version 1.4.1 SRM, we see in the example exactly why the requirement statement is only partially inheritable (namely due to the fact that only one in three of its evaluative elements are inheritable). Therefore, treating just the second evaluative element as inheritable from the CSP is now possible. The assessed entity is fully responsible for the other two evaluative elements. 

A similar example holds for full inheritance. An example as follows: 

Example 2

Baseline Unique ID (BUID): 1165.01cPCISystem.1

Cross-version ID (CVID): 0066.0

HITRUST CSF v11 Requirement Statement: A service provider protects each organization’s hosted environment and data by: (1) ensuring that each organization only runs processes that only have access to that organization’s cardholder data environment and (2) restricting each organization’s access and privileges to only its cardholder data environment.

Requirement-level inheritability: Fully inheritable

Number of Evaluative Elements: 2, as follows:

• EE #1 (fully inheritable): A service provider protects each organization’s hosted environment and data by ensuring that each organization only runs processes that only have access to that organization’s cardholder data environment.
• EE #2 (fully inheritable): A service provider protects each organization’s hosted environment and data by restricting each organization’s access and privileges to only its own cardholder data environment.

When a requirement statement is fully inheritable (as is the case in this example), the assessed entity could have treated the whole requirement statement as 100% responsibility on the CSP (dependent on the assessment’s scope). The transparency afforded through SRM v1.4.1 into the evaluative element-level inheritability for fully inheritable requirements is less impactful than it is on partially inheritable requirements, as the inheritability of all elements must be “fully inheritable” in order for the requirement statement-level inheritability to be “full inheritable”.

Additional Resources

Below are additional resources that provide a deeper dive into the topics covered in this blog post:

HITRUST Advisories with the SRM Update

HITRUST Shared Responsibility and Inheritance Program  

We Can Help

The 1.4.1 update to the SRM provides new insight into how HITRUST views that inheritance should be applied. If you have questions about the updated HITRUST v1.4.1 SRM, the Inheritance Program or would like to speak with our team of experienced HITRUST and healthcare security experts, please call at (833) 292-1609 or email at sales@tevora.com.