HITRUST provides Assessed Entities with a method for placing reliance on previously assessed HITRUST-compliant control environments by utilizing inheritance. Inheritance may reduce and/or eliminate the need for duplicative control assessment testing by Assessed Entities and/or External Assessors during a HITRUST assessment.
The inheritance function provides Assessed Entities and External Assessors the ability to inherit previously assessed HITRUST control testing maturity scores (and pertinent commentary) from any other qualified “inheritable” HITRUST assessment. HITRUST requirement statements may be inherited into/from any version of the HITRUST CSF (cross-version inheritance).
While performing a HITRUST assessment Assessed Entities have the option to use internal and/or external types of inheritance:
- Internal inheritance uses the inheritance functionality to share assessment results between assessments of a single organization (e.g., between a shared IT service and a business unit).
- External inheritance uses the inheritance functionality to share assessment results between assessments of different organizations (e.g., between a CSP and its tenants).
12.2.1 Inheritance into a validated or readiness assessment (for any assessment type) is allowed from the following assessment types while the certification or validated-only report* for each assessment is active and in good standing:
- HITRUST Essentials, 1-year (e1) Validated Assessment
- HITRUST Implemented, 1-year (i1) Validated Assessment
- HITRUST Risk-based, 2-year (r2) Validated Assessment
*NOTE: For r2 validated-only (i.e., non-certified) reports, inheritance is only allowed one year from the report date.
12.2.2 Inheritance from a readiness or incomplete validated assessment (for any assessment type) is only allowed into a readiness assessment (utilizing internal inheritance). Inheritance from those assessments is not allowed into a validated assessment since it has not completed the HITRUST Quality Assurance review process (see Chapter 14 Undergoing Quality Assurance).
An Assessed Entity will fall into one of the following roles during the inheritance process:
- Inheritance User (also may be called a “Tenant”): The Assessed Entity which owns the “inheriting” assessment. The Inheritance User is placing reliance on controls that were previously assessed and validated in a separate HITRUST assessment. The separate assessment may be owned by another organization (external inheritance) or the same organization (internal inheritance).
- Inheritance Provider: The Assessed Entity which owns the “inheritable” HITRUST assessment.
HITRUST has established the following requirements for Inheritance Users:
12.2.3 Inheritance Users may directly apply internal inheritance scores to the corresponding requirement statement. See MyCSF Help | User Guide for detailed instructions.
12.2.4 Inheritance Users must submit all external inheritance requests to the Inheritance Provider using the automated approval workflow process. See MyCSF Help | User Guide for detailed instructions.
12.2.5 For external inheritance requests, the Inheritance User must use the HITRUST Shared Responsibility Matrices (SRMs) that are available for download from MyCSF or the HITRUST website (HITRUST Shared Responsibility and Inheritance Program – HITRUST Alliance) to help identify which requirement statements can be inherited based on their corresponding SRM Type designations.
12.2.6 Inheritance Users must use the SRM specific to the service provider in scope of its assessment when available. When the service provider does not offer a provider-specific SRM, the Inheritance User must use the baseline SRM template.
12.2.7 The SRM may not be used to support scoring within the validated assessment. Reliance on a service provider’s HITRUST assessment must be done utilizing inheritance or attaching a HITRUST validated assessment report.
12.2.8 Inheritance Users must submit all inheritance requests to the “inheriting” HITRUST assessment prior to the end of the 90-day assessment fieldwork period and no more than 30 days prior to the start of fieldwork.
12.2.9 Inheritance Users must have a valid business justification for use of inheritance supported by a strategy and approach for the appropriate level of control reliance.
12.2.10 Requirement statements that have been marked as ‘Not Applicable (N/A)’ by the Inheritance Provider, but marked inheritable in the SRM, may be inherited by the Inheritance User in their HITRUST assessment. For scoring information, see Chapter 8.3 Not Applicable (N/A) Requirement Statements.
HITRUST has established the following requirements for Inheritance Providers:
12.2.11 For an Inheritance Provider to allow external inheritance requests, it must enable the use of external inheritance and consent to external Inheritance User terms and conditions. See MyCSF Help | User Guide for detailed instructions.
12.2.12 Inheritance Providers should process (approve or reject with comment) external inheritance requests in a timely manner to help ensure Assessed Entities are able to apply all approved external inheritance requests before the end of the 90-day assessment fieldwork period.
12.2.13 Inheritance Providers must validate the following when considering approving or rejecting an external inheritance request:
- Request is from a valid Customer of the Inheritance Provider.
- The Customer has purchased/contracted with the Inheritance Provider the service(s) in scope of the assessment.
- The inheritance weight is within the boundaries the Inheritance Provider has established or the rationale for a higher weight has been agreed with the Inheritance Provider.
12.2.14 If the Inheritance Provider has questions or concerns on an inheritance request, it should engage directly with the Inheritance User in a timely manner.
12.2.15 Inheritance Providers are eligible to create and publish a HITRUST SRM tailored for its “inheritable” HITRUST assessment. The HITRUST SRM provides a mechanism for Inheritance Providers to communicate expectations to Inheritance Users to streamline inheritance request processing (e.g., partial inheritance weight limits, support contact information, and processing lead-time or Service Level Agreements (SLAs), if applicable).
12.2.16 A HITRUST assessment that reaches its expiration date will automatically unpublish on the expiration date of the certification, which disables the assessment’s inheritability.
12.2.17 Prior to an assessment being unpublished, Inheritance Providers should respond to all open inheritance requests.
12.2.18 Inheritance Providers should publish their recertified assessment for inheritance in a timely manner to minimize any downtime impact on their Inheritance Users. Inheritance Providers can work directly with their HITRUST Customer Success Manager (CSM) or contact HITRUST Support to migrate any outstanding external inheritance requests (i.e., with status of created or submitted and not approved or rejected) from an expired assessment to a new HITRUST assessment.
12.2.19 A bridge certificate (see Chapter 15.8 Bridge Assessments) does not extend the expiration date of a HITRUST report. As a result, an “inheritable” HITRUST assessment with a bridge certificate will not extend the assessment’s inheritability.
Inheritance scoring
Requirement statements must be scored for each service provider that manages performance of the corresponding HITRUST requirement statement within an Assessed Entity’s assessment (unless the service provider is carved out – see Chapter 7.3 Carve-outs). In situations where control performance responsibility is shared between the Assessed Entity and/or one or more Inheritance Providers, the Assessed Entity and/or its External Assessors should determine a corresponding amount of responsibility for each party based on its role within the scope of the assessment. In situations where there is one service provider that is responsible for a particular requirement statement in its entirety, the Assessed Entity may be able to request full inheritance from the provider. However, in situations where the responsibility is shared, either between the Assessed Entity and a Service Provider or between multiple Service Providers, the Inheritance User (i.e., Assessed Entity) will utilize partial inheritance instead of full inheritance.
For partial inheritance, the Inheritance User assigns a percentage to each corresponding responsible party (i.e., Assessed Entity or Inheritance Provider(s)) on a per requirement statement basis to produce a weighted average which represents the resulting maturity score for each requirement statement. After assigning the corresponding weights, MyCSF will automatically calculate the score based on the assigned weights and inherited scores. HITRUST offers Assessed Entities and its External Assessors an Inheritance Calculator tool to preview how inheritance scores and weights impact assessment scoring.
HITRUST has established the following requirements for inheritance scoring:
12.2.20 In situations where an SRM allows inheritance (either partial or full), inheritance may not be used if the Assessed Entity has the sole responsibility, authority and accountability over the control’s implementation and enforcement to achieve control compliance.
12.2.21 Full inheritance may only be asserted if responsibility for performance of a requirement statement, in its entirety, is functionally outsourced to the Inheritance Provider, and therefore, the Assessed Entity is completely reliant upon the Inheritance Provider. In addition, the corresponding SRM for the Inheritance Provider (or baseline SRM when the provider does not have an SRM) should indicate the full inheritance is allowed. In cases where the SRM does not allow full inheritance, the Inheritance User must agree with the Inheritance Provider to utilize full inheritance.
12.2.22 Partial inheritance must be used if responsibility for performance of a control to address a HITRUST requirement statement is shared, either between the Assessed Entity and the Inheritance Provider(s), or between multiple Inheritance Providers (if fully outsourced).
12.2.23 To assign an appropriate inheritance weight percentage, the Inheritance User must determine the percentage of the assessment scope and/or control responsibility which is outsourced, and whether that responsibility is fully or partially covered, by the Inheritance Provider’s scoring. The defined weight percentage may or may not be the maximum percentage allowed by the Inheritance Provider and/or HITRUST SRM since it is based on the corresponding control responsibility. The Inheritance User must agree with the Inheritance Provider for any weight percentage above the maximum allowed in the SRM. For examples of inheritance calculations, please see Appendix A-12: Inheritance FAQs & Examples.
12.2.24 The percentage weights assigned by the Inheritance User between the Assessed Entity and/or Inheritance Provider(s) must include a documented rationale within the MyCSF requirement statement validated by the External Assessor. The rationale should be based on the amount of responsibility for each party related to the control environment and scope of the assessment. Since responsibilities may vary per control, requirement statements may have different weights (and rationales).
12.2.25 For external inheritance, the Inheritance User cannot modify the Inheritance Provider’s originating control maturity scores from the “inheritable” HITRUST assessment once applied to the “inheriting” HITRUST assessment. Inheritance Users may modify scores applied using internal inheritance.
Since requirement statements marked as ‘N/A’ are not scored, the following provides an explanation of how inheriting an ‘N/A’ impacts the Assessed Entity’s assessment scoring calculation:
- Full (100% weight) Inheritance ‘N/A’ Scoring: The inherited requirement statement is marked as ‘N/A’ within the Assessed Entity’s assessment and not scored. It is excluded from the aggregate domain maturity score. The inherited ‘N/A’ rationale is included in the final report.
- Partial Inheritance ‘N/A’ Scoring: The inherited requirement statement is not marked as ‘N/A’ within the Assessed Entity’s assessment and the directly tested (non-inherited) portion of the requirement statement is scored. The inherited requirement statement is not included in the numerator or denominator during the scoring calculation (for both the requirement statement and domain scoring).
For further information and examples on inheritance, please see Appendix A-12: Inheritance FAQs & Examples. For the latest version of the Shared Responsibility Matrix, see HITRUST Shared Responsibility and Inheritance Program – HITRUST Alliance.