Why use inheritance instead of other methods of control reliance on previously assessed requirement statements?
The HITRUST Shared Responsibility and Inheritance Program offers Assessed Entities a unique and innovative alternative method for placing reliance on previously assessed HITRUST-compliant control environments by utilizing inheritance.
- Inheritance eliminates the need for duplicative control assessment testing that can save Assessed Entities (and their External Assessors) considerable time, effort, and cost when planning, performing, and validating a HITRUST assessment.
- For relying parties, traditional manual reliance methods are problematic and time-consuming when a third-party service provider’s offline compliance reports lack sufficient transparency needed for scoring HITRUST assessments or force external control carve-outs when reports are not shared. This problem is solved by utilizing inheritance in conjunction with the HITRUST Shared Responsibilities Matrix® (SRM) when relying on third-party service providers that are HITRUST Certified and getting clarity over how control responsibility is shared.
- For Assessed Entities (and their External Assessors), users gain the ability to inherit previously-assessed requirement statement testing (and pertinent commentary) from any other qualified “inheritable” HITRUST assessment. Further, cross-version inheritance is supported which allows requirement statements to be inherited into/from HITRUST assessments generated from any version of the HITRUST CSF. This is enabled by MyCSF which can systematically identify and link to cross-version control matches that span any supported version of the HITRUST CSF.
Who is allowed to use inheritance, and does it depend on whether I use the external or internal types of inheritance?
As specified in Chapter 12 Reliance & Third-Party Coverage, HITRUST customers with an active annual MyCSF subscription can use inheritance. Inheritance is not allowed for use by ‘Report-Only or ‘Lite’ MyCSF subscribers. More specifically, external inheritance can be used by Assessed Entities with a professional-level MyCSF subscription and Inheritance Providers must have corporate- or premier-level MyCSF subscriptions to be able to “publish” (or enable) their HITRUST assessments to be “inheritable” by other Assessed Entities. Internal inheritance differs, such that, all users must have a corporate- or premier-level MyCSF subscription and Inheritance Providers and Assessed Entities must belong to the same organization.
Which HITRUST assessments support use of inheritance?
The following assessment types (and assessment status) can qualify as “inheritable” HITRUST assessments:
- For external inheritance, Assessed Entities can inherit from “published” Risk-based, 2-year (r2), Implemented, 1-year (i1) and Essentials, 1-year (e1) Validated Certified and Validated-Only (Non-Certified) Assessments that are complete and with a report date posted.
- For internal inheritance, Assessed Entities can inherit from their own Risk-based, 2-year (r2), Implemented, 1-year (i1) and Essentials, 1-year (e1) Validated Certified, and Validated-Only (Non-Certified) that are complete (and with a report date posted for validated assessments).
Can I inherit from a targeted, current state (tC) assessment?
No.
Is it possible to inherit from a Risk-based, 2-year (r2) type of HITRUST assessment into an Implemented, 1-year (i1) or Essentials, 1-year (e1) HITRUST assessment (and vice versa)?
Yes. As specified in Chapter 12 Reliance & Third-Party Coverage), requirement statements can be inherited between the various assessment types (Risk-based, 2-year (r2), Implemented, 1-year (i1) and Essentials, 1-year (e1)). However, when inheriting from an “inheritable” i1 or e1 into an “inheriting” r2, only the Implemented maturity score can be inherited. It is therefore incumbent upon the Assessed Entity to be prepared to cover the remaining control maturity scores that cannot be inherited (e.g., Policy, Procedure, Implemented if partially inherited, and Measured or Managed, if applicable).
When using external inheritance, when is it appropriate to request full versus partial inheritance, and if partial, what should be the appropriate inheritance weight?
When using external inheritance, Assessed Entities should have a documented strategy and approach for placing the appropriate level of control reliance (“inheritance weights”) for those requirement statements that are covered by (or shared with) third-party service providers. As stated in criteria 12.2.22 (see Chapter 12.2 Reliance on Assessment Results Using Inheritance) 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 percentage is based on the following:
- The use of full inheritance is appropriate when a third-party service provider performs 100% of the requirement statement on behalf of the Assessed Entity.
- The use of partial inheritance is appropriate when either of the following apply:
- The Assessed Entity performs a portion (< 100%) of the requirement statement and the remaining is covered by one or more third-party service providers.
- Multiple third-party service providers split performance of 100% of the requirement statement on behalf of the Assessed Entity.
Assessed Entities can use HITRUST SRMs as a baseline inheritance guideline, available for download from MyCSF or the HITRUST website, to help identify which requirement statements can be inherited based on their corresponding SRM Type designations. Assessed Entities can also use HITRUST’s interactive Inheritance Calculator to test out various full and partial inheritance scenarios via: https://help.mycsf.net/inheritance-calc/.
Can I inherit requirement statements that are marked as N/A? If so, how are they scored within the HITRUST assessment?
Yes. External and internal inheritance is allowed for requirement statements marked as N/A but are scored differently depending on whether full or partial inheritance was applied:
- Full inheritance: The requirement statement is not included when calculating the domain-level aggregate score within the qualified “inheriting” HITRUST assessment.
- Partial inheritance: The final score is derived from the “applicable” portion of the requirement statement that was scored by the Assessed Entity (or inherited from another third-party service provider), ignoring the inherited portion marked as N/A. The resulting final score is included when calculating the domain-level aggregate score within the qualified “inheriting” HITRUST assessment.
For external inheritance, it is a good practice for Assessed Entities to reference HITRUST SRMs that are tailored for Inheritance Providers (if available). The HITRUST SRMs tailored for Inheritance Providers include a standardized set of N/A commentary providing Assessed Entities with supplemental context and guidance for the appropriate application of “inheritance weights” for requirement statements marked as N/A.
For additional user guidance on the use and scoring of requirement statements marked as N/A, refer to Chapter 8.3 Not Applicable (N/A) Requirement Statements and 12.2 Reliance on Assessment Results Using Inheritance. To explore various inheritance scenarios with requirement statements marked as N/A, visit HITRUST’s interactive Inheritance Calculator via: https://help.mycsf.net/inheritance-calc/.
Can I pick and choose which of the requirement statement’s control maturity scores to inherit (i.e., only inherit the Policy and Procedure control maturity scores but not Implemented, Measured, and Managed)?
No. When using either external or internal inheritance, the entire set of maturity scores that have been assessed for a specific requirement statement are inherited into a HITRUST assessment. However, if only the Implemented maturity level is available in the Inheritance User’s assessment (i.e., in an i1 or e1) the Assessed Entity may inherit only the Implemented maturity score from the Inheritance Provider. Additionally, if the Inheritance Provider performed an i1 or e1 then only the Implemented maturity score will be available for the Inheritance User to inherit.
I created and then submitted several external inheritance requests to an Inheritance Provider, but they have not yet been approved. How long is a reasonable timeframe to wait and is there a way to ask for a status update or if there is an SLA for the timely processing of external inheritance requests?
All inheritance requests within a qualified “inheriting” HITRUST assessment (see Chapter 12.2 Reliance on Assessment Results Using Inheritance) must be:
- “created” and “submitted” by the Assessed Entity,
- “approved” by the Inheritance Provider, and
- “applied” by the Assessed Entity (using the built-in automated workflow process within MyCSF)
In order to utilize testing results from the Inheritance Provider, each inheritance request must be completed prior to the end of the 90-day assessment fieldwork period. It is therefore incumbent upon Assessed Entities to submit external inheritance requests as soon as possible upon initiating the HITRUST assessment process and Inheritance Providers should also make reasonable efforts to process external inheritance requests in a timely manner.
If Assessed Entities have “submitted” external inheritance requests, but have not received a response (approval or rejection with comment) from the Inheritance Provider within a reasonable timeframe (i.e., 10 or more business days), Assessed Entities have the following escalation options:
a) Assessed Entities may contact the Inheritance Provider directly using the customer support contact information included in the Inheritance Provider’s HITRUST SRM (if available), or
b) The Assessed Entity may contact their CSM or HITRUST Support (support@HITRUSTalliance.net).
I am unable to request external inheritance from a third-party service provider included in the scope of my HITRUST assessment. Why is that the case?
Assessed Entities may be unable to utilize external inheritance due to one of the following situations:
- The third-party service provider may not be HITRUST certified, or its HITRUST certification may have lapsed. If the third-party service provider is not (or no longer) HITRUST Certified, utilizing external inheritance is not possible.
- The third-party service provider may only have a professional-level MyCSF subscription, or the third-party service provider may have a corporate- or premier-level MyCSF subscription but they have not yet “published” the HITRUST assessment. In either case, Assessed Entities are encouraged to notify HITRUST if there are any third-party service providers that should be external Inheritance Providers via the MyCSF UserVoice online user feedback forum.
- The third-party service provider is already an Inheritance Provider with a “published” HITRUST assessment, however, the requested requirement statement(s) cannot be inherited. This will occur when the Inheritance Provider did not have the corresponding requirement statement(s) within their validated assessment, which may occur because:
- The assessment factors used to generate the HITRUST assessment object for the Inheritance Provider did not bring that requirement statement into its validated assessment, and/or
- The version of the HITRUST CSF used to generate the HITRUST assessment object for the Inheritance Provider did not contain that requirement statement.