ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
HITRUST inheritance lets you reuse control results that another party has already had assessed, so that your own assessment covers only what you actually run. For a company building on a major cloud platform, it can remove a large share of the work, but only if you understand what can be inherited, from whom and with what evidence.
This guide explains how inheritance works in a HITRUST assessment, what the Shared Responsibility Matrix does, how to plan the scope around it and where it stops helping. For the assessment types, see our HITRUST assessments guide.
Free gap assessment
Could you evidence your HIPAA safeguards today?
Score every standard and implementation specification, free, including the addressable ones that still need a decision on file.
Run the free HIPAA gap assessment → or View premium report sample
HITRUST describes its Shared Responsibility and Inheritance Program as a way to reuse inheritable controls from internal and external third-party organisations. External inheritance takes results from a cloud service provider, hosting provider or other vendor whose controls have already been assessed. Internal inheritance takes results from one of your own HITRUST assessments and applies them to another, for example when two products share the same corporate policies and data centre.
The logic is simple. If your cloud provider operates the physical security, the hypervisor and the underlying network, and its controls have been validated in its own HITRUST assessment, you should not have to test the same controls again. You inherit the result and concentrate on the parts that are yours: the configuration of your workloads, your access management, your application security and your own processes.
The mechanism that makes this work is the Shared Responsibility Matrix, or SRM. HITRUST publishes matrices with major cloud providers that set out who owns each control in a cloud environment, so that responsibility is clear and not assumed. HITRUST describes them as baseline templates with pre-populated shared responsibility and inheritance for leading cloud platforms, and as a way to define which conditions allow external inheritance.
| Ownership model | Meaning for your assessment |
|---|---|
| Provider-owned | The provider operates the control, and you can inherit its assessed result |
| Shared | Both parties contribute, so you assess your part and inherit the provider’s part |
| Customer-owned | You operate the control and must evidence it yourself |
The exact categories and labels in the matrices may differ by version, so use the version that matches your assessment year, and read the provider’s current matrix before you scope. The idea is the same as the customer responsibilities in other frameworks, which we discuss in our complementary user entity controls guide.
HITRUST states that organisations can inherit as much as 70 to 85 percent of the requirements in assessments from participating cloud providers. Treat that as a best case from the programme’s own description. Your figure depends on your architecture: a fully cloud-native service on a single platform inherits far more than a hybrid environment with your own data centre and several vendors. Do the mapping for your own environment before you promise a number to a customer or to your board.
To inherit, you generally need documented evidence from the provider that the control was assessed and that the result is current, plus the matrix showing how responsibility is divided for your service. In practice, that means checking four things before you rely on inherited results.
Your external assessor will validate the inheritance decisions, so involve them early. Our HITRUST external assessor guide lists questions to ask before you choose one.
Start from your architecture diagram and list every third party that touches the in-scope system: cloud infrastructure, managed databases, identity providers, monitoring tools, payment processors and support vendors. For each one, decide whether it offers an assessed result you can inherit, whether a shared responsibility matrix exists and what remains yours. Then map the requirements. A requirement statement may be fully inherited, partly inherited or entirely yours. Record the reasoning in a table, with a reference to the provider’s evidence, so that your assessor can trace each decision.
Watch for gaps. Some requirements sit between parties and are covered by neither. A classic example is a provider-managed service that leaves logging configuration to the customer: the provider secures the platform, but nobody has been assigned the retention setting. Fill such gaps in your own scope, and document them.
A digital health company runs a patient messaging platform on a single major cloud provider that participates in the programme. It lists its third parties, finds that the cloud provider, its managed database service and its email delivery vendor have assessed results, and downloads the current matrix. It marks physical, environmental and much of the network layer as inherited, marks identity management, application security and incident response as its own, and notes logging retention as a gap that it must cover. The assessor reviews the table, tests the company’s own controls and validates that the inherited items match the matrix. The example is illustrative only.
Companies with several products or business units often run more than one HITRUST assessment. Internal inheritance allows results from one assessment to support another where the same controls genuinely apply, such as shared corporate policies, a common identity platform or a shared security operations centre. The benefit is consistency and less rework, but the condition is real sameness. If two products use different infrastructure, different teams or different tooling, the controls are not the same and each needs its own evidence. Keep a register of controls you treat as shared, name the owner and review the sameness claim each year.
The same discipline helps with year-over-year work. Results validated in one assessment period can support the next only within the limits of the framework, so record which items were carried forward and why, and verify that nothing significant changed in between.
Inheritance reduces the number of requirements you must test and evidence, which usually reduces both internal effort and assessor hours. It does not remove the fixed costs of the programme. See our HITRUST certification cost guide for the drivers, and our HITRUST interim assessment guide for the second-year work, where inherited results also need refreshing. Plan a review of provider results before each assessment window so surprises are found early.
Good inheritance depends on communication. Ask your account team at the provider for the current matrix and for confirmation of which of its services are covered. Share your architecture with the assessor before the assessment begins and ask them to confirm your proposed inheritance approach. If a provider changes a service, adds a region or retires a feature, review the effect on your table. Keep contact details for both the provider’s compliance team and your assessor in one place, because questions come up close to deadlines. A short kickoff call where all three parties agree on scope prevents most disputes later.
A good working set is an inheritance map by requirement, a third-party register with evidence links, a gap log and a review calendar. The HITRUST CSF Toolkit includes templates that support scoping and evidence organisation, which you can adapt to your environment. For the programme itself, see HITRUST’s Shared Responsibility and Inheritance Program page, and check the current matrices for your provider.
It is the reuse of control results from a third party, such as a cloud provider, or from your own earlier assessments, so that you do not retest the same controls.
HITRUST states that up to 70 to 85 percent of requirements can be inherited from participating providers, but your actual figure depends on your architecture and usage.
A document that sets out which party owns each control in a cloud environment, and which controls can be inherited from the provider.
The external assessor validates your inheritance decisions against the evidence and the matrix, so document them clearly and involve the assessor early.
September 30, 2026
