HITRUST Inheritance: How to Inherit Controls From Certified Cloud and Service Providers

Short answer: HITRUST inheritance lets you reuse control results from a provider's HITRUST validated assessment inside your own assessment in MyCSF. You request inheritance for eligible requirements, the provider approves the request, and its scores flow into your assessment. Controls can be fully or partially inherited, while your application, people and process controls stay yours.

Related guides:

• HITRUST certification guide
• HITRUST vs SOC 2
• HITRUST compliance checklist

Key takeaways

• Inheritance reuses validated results. You rely on a provider's HITRUST validated or certified assessment instead of testing the same control twice.
• Not every control is equal. Requirements are fully inheritable, partially inheritable or not inheritable, and partial ones still need your own evidence.
• The provider must approve. External inheritance runs through an approval workflow in MyCSF where the provider authorizes sharing its results.
• e1, i1 and r2 all participate, with scoring limits when you inherit from a lighter assessment into a heavier one.
• Your assessor still validates. Inherited scores do not remove the need to show how your side of each shared control works.

What is HITRUST inheritance?

HITRUST inheritance is the mechanism in MyCSF that lets one assessment rely on the scored results of another HITRUST assessment for the same requirement.

It sits inside the HITRUST Shared Responsibility and Inheritance Program, which HITRUST says allows organizations to reuse inheritable controls from internal and external third-party organizations, including vendors, major cloud service providers and the organization's own existing HITRUST validated or certified assessments.

HITRUST describes two forms in its MyCSF inheritance presentation:

Form	Who shares with whom	Typical HealthTech example
Internal inheritance	Between assessments of the same organization	A central IT or platform team assessment shared with a product line assessment
External inheritance	Between assessments of different organizations	A cloud platform or managed service provider sharing with its tenants

For most HealthTech SaaS companies, external inheritance from the cloud platform is the big one. Physical data center security, hardware lifecycle and parts of the infrastructure layer are operated by the provider, and you could not test them yourself anyway.

On effort, HITRUST's program page states that organizations can inherit as much as 70% to 85% of requirements in HITRUST assessments from participating cloud service providers. Treat that as an upper bound from HITRUST, not a forecast. Your share depends on your scope, the services you use and how much of your stack runs on that provider. For budget and schedule planning, see our guides to HITRUST certification cost and HITRUST timelines.

Full vs partial inheritance: what is the difference?

Full inheritance means the provider owns and has validated the whole requirement, while partial inheritance means you reuse the provider's result for its portion and still prove your own portion.

HITRUST's inheritance eBook groups requirements into three classes:

Class	What it means	What you still do
Fully inheritable	Fully managed by the provider and already validated	Confirm the requirement applies to the services you use, then inherit
Partially inheritable	Provider results cover part of the requirement	Document and evidence your implementation in your own environment for assessor review
Not inheritable	Entirely your responsibility	Implement, document and have it assessed like any other control

Under the hood, HITRUST's 2022 MyCSF material describes partial inheritance as a weighting between the provider's score and yours, and HITRUST offers an inheritance calculator because combining those scores "can be complex." The calculator supports varied weights per provider and inheritance from multiple providers, which matters if you inherit from both a cloud platform and, say, a managed logging service.

A practical rule: a weak implementation on your side drags down a partially inherited score, however strong the provider's portion is.

Which HITRUST assessments support inheritance?

All three current HITRUST validated assessment types, e1, i1 and r2, can take part in inheritance, but inheriting across types has limits.

What HITRUST's primary sources confirm:

• e1. The e1 introduction advisory states that i1 or r2 results can be inherited into an e1 assessment and vice versa. Because e1 scores only the implemented maturity level, only that level's scoring carries over when inheriting from an e1 into an r2.
• i1 and r2. HITRUST's MyCSF inheritance presentation lists r2 and i1 validated assessments as sources for external inheritance, and the inheritance calculator supports inheritance across assessment types, with an i1 into r2 example.
• Eligibility of the source. The provider's assessment must be completed with a final report and published for external inheritance in MyCSF. HITRUST's Assessment Handbook v1.2 advisory (January 2026) notes that the handbook clarifies inheritance eligibility based on certification status and certification expiration dates, so check the current handbook before you plan around a provider's report.

The takeaway for planning: pick a provider whose assessment type and scoring depth match the assessment you are pursuing. If you are working toward an r2, inheriting from a provider's e1 leaves the other maturity levels for you to score.

Can you inherit controls from AWS, Azure and Google Cloud?

Yes, the major cloud platforms publish HITRUST shared responsibility matrices, and HITRUST and the providers describe inheritance through MyCSF, provided you use in-scope services and implement your side.

HITRUST announced in January 2021 shared responsibility matrices built with AWS and Microsoft Azure, each documenting which HITRUST CSF controls are full, partial or shared responsibility, along with MyCSF support for inheriting from those providers. As of October 2026, the providers' own pages say:

• AWS. The AWS HITRUST page says customers can inherit AWS's certification for controls pertinent to their cloud architectures, provided they use only HITRUST-certified services and apply the controls described in the AWS HITRUST shared responsibility matrix.
• Microsoft Azure. The Azure HITRUST offering page explains that you pre-populate your MyCSF assessment with fully inherited or shared responsibility controls for Azure, and a Microsoft HITRUST administrator completes Microsoft's part. It also says you remain ultimately responsible for your own HITRUST CSF compliance.
• Google Cloud. The Google Cloud HITRUST page states that Google Workspace and Google Cloud have achieved HITRUST CSF certification and that a shared responsibility matrix developed jointly with HITRUST is a free download.

HITRUST also offers a free baseline shared responsibility matrix template for providers that have not published their own. Whichever provider you use, confirm that every service in your architecture is in the provider's certified scope. A database or AI service outside that scope gives you nothing to inherit.

How do you request inheritance in MyCSF?

You create and submit inheritance requests from your own assessment, the provider reviews and approves or rejects them, and approved results are applied to your requirements.

Based on HITRUST's MyCSF inheritance guidance, a workable sequence for a HealthTech SaaS team looks like this:

1. Scope your assessment. Finalize the in-scope systems, services and assessment type so you know which requirements apply.
2. Download the provider's matrix. Use the provider-specific shared responsibility matrix, or the HITRUST baseline template, to see which requirements are fully, partially or not inheritable.
3. Confirm service coverage. Check that every cloud service you use is in the provider's certified scope and that the provider's assessment is current and published for inheritance.
4. Map requirement by requirement. For each requirement, decide whether to inherit fully, partially or not at all. Do not inherit a control just because it is available.
5. Create and submit requests. As the assessed entity, create inheritance requests in MyCSF and submit them to the provider.
6. Provider review. The provider approves or rejects each request. Inherited scores and commentary become visible only after approval.
7. Apply the results. Apply approved inheritance to your requirements, then score and evidence your own portion of partially inherited ones.
8. Assessor validation. HITRUST's guidance says your external assessor must validate that each control is implemented as described, including the portion that relies on the third party.

Start this early. Provider approval is outside your control, and in our experience teams that submit requests late end up testing controls they could have inherited.

What cannot be inherited?

Anything you design, build or run yourself cannot be inherited, which for a SaaS company means your application, your people and your processes.

HITRUST's eBook lists internal security policies and procedures and your independent risk management process among the controls that remain your responsibility. In practice, expect to own:

• Application security. Secure development, code review, vulnerability management for your code and dependencies.
• Identity and access in your product and accounts. Who can reach production, cloud console access, MFA enforcement and access reviews.
• Your configuration of cloud services. Encryption settings, network rules, logging and backup choices you make inside the provider's platform. These are usually shared, not inherited.
• People controls. Security awareness training, onboarding and offboarding, background checks where required.
• Governance and process. Policies, risk assessment, incident response, vendor management and business continuity planning.
• Endpoints. Laptops and devices your workforce uses to reach production or PHI.

Our HITRUST compliance checklist covers how to prepare evidence for these owned controls.

How do you document the shared responsibility split?

Record, for every in-scope requirement, who owns it, whether you inherit it, from which provider assessment, and what evidence covers your portion.

The table below shows example values for a SaaS company on a single cloud platform. They are examples only. Your provider's matrix is the authority for what is actually inheritable.

Control area (example)	Owner (example)	Inheritance (example)	Your evidence (example)
Physical data center security	Provider	Full	Provider matrix entry and service scope check
Hardware disposal in the data center	Provider	Full	Provider matrix entry
Encryption of stored data	Shared	Partial	Screenshots or exports showing encryption enabled on your storage
Network security and segmentation	Shared	Partial	Your network rules and architecture diagram
Logging and monitoring	Shared	Partial	Your log retention settings and alert review records
Application access control	You	None	Access review records and MFA configuration
Security awareness training	You	None	Training completion records
Risk assessment	You	None	Current risk register and assessment report

Keep this mapping as a living document. When you add a new cloud service or provider, update the matrix, confirm its HITRUST scope and raise new requests. When the provider's assessment is renewed, check that your inherited results still point to an eligible report.

How SecureSlate helps

SecureSlate helps HealthTech teams organize the work that surrounds HITRUST inheritance. Built-in HITRUST support with multi-framework control mapping to HIPAA, SOC 2 and ISO 27001 lets you see where one control satisfies several requirements, and custom controls let you record ownership, inheritance status and the provider assessment you rely on. Agentless read-only cloud integrations help you gather evidence for your side of shared controls such as encryption and logging, while the device agent covers endpoints. Vendor risk management tracks your providers and their reports, access reviews and risk management cover controls you cannot inherit, and audit management keeps evidence ready for your external assessor. The trust center and security questionnaire automation help you explain your shared responsibility model to customers.

FAQ

Does inheriting from a HITRUST-certified cloud provider make my company HITRUST certified?

No. The provider's certification covers its own environment. You still need your own assessment, and inherited results only cover the provider's portion of the requirements that apply to you.

Can I inherit from a SOC 2 report instead of a HITRUST assessment?

Not through MyCSF inheritance, which relies on HITRUST assessment results. A provider's SOC 2 report can still support your own evidence for vendor and shared controls, as covered in our HITRUST vs SOC 2 guide.

Who approves an inheritance request?

The provider whose assessment you want to inherit from. External inheritance uses an approval workflow in MyCSF where the provider authorizes sharing its results with you.

Can I inherit controls from more than one provider?

Yes. HITRUST's inheritance calculator supports inheritance from multiple providers with different weights, which is common when you use a cloud platform plus other HITRUST-assessed service providers.

Disclaimer (legal note)

This article is for general information only and is not legal, regulatory or professional advice. Requirements vary by framework, industry and jurisdiction. Consult qualified advisors for your specific obligations.