HITRUST Inheritance: What You Can Actually Reuse

HITRUST states that with inheritance from prior assessments, "organizations can inherit as much as 70%-85% of requirements in HITRUST assessments from participating CSPs", on the page for its Shared Responsibility and Inheritance Program, which is HITRUST's own marketing for a program it operates and benefits from. Read the conditional that a participating provider attaches to the same idea: AWS states that "AWS customers can inherit AWS HITRUST CSF certification provided that customers use only HITRUST-certified services and apply the controls detailed in the HITRUST Shared Responsibility Matrix" (AWS HITRUST page). The ceiling is real. The conditional is where most organisations lose the difference between 85 percent and the number they actually get, because almost nobody runs exclusively on the certified subset of a cloud provider's service catalogue.

This piece covers what inheritance is in HITRUST's own words, the conditional attached to the headline number, the internal inheritance nobody markets, what the Shared Responsibility Matrix actually is, why inheriting a control does not move the risk, and the mechanics HITRUST's public pages decline to describe.

Key takeaways

• HITRUST publishes the inheritance ceiling as "as much as 70%-85% of requirements" from participating CSPs. It is a vendor figure with no published method and an upper bound, not a planning assumption.
• AWS conditions inheritance on using only HITRUST-certified services and applying the matrix. Service selection, not paperwork, is what determines your real percentage.
• Controls can be inherited from external parties (vendors, major CSPs) and internally, from your organisation's own existing HITRUST Validated or Certified Assessments.
• The Shared Responsibility Matrix is the artifact that decides who owns what. HITRUST publishes downloadable matrices plus a free baseline template.
• Inheritance moves evidence, not accountability. You still answer for the control to your customer.

What inheritance is, in HITRUST's own words

HITRUST describes the program as allowing "organizations to reuse inheritable controls from internal and external third-party organizations", with controls inheritable from vendors, major cloud service providers, and your organisation's own existing HITRUST Validated or Certified Assessments.

The mechanism it leans on hardest is cloud. Because major cloud providers hold HITRUST certifications, HITRUST says customers pursuing certification "can automatically inherit their CSP's security controls, making it easier and quicker to achieve security certification." AWS confirms the provider side of that, stating that specific AWS services "have been assessed under the HITRUST CSF Assurance Program by an approved HITRUST CSF Assessor as meeting the HITRUST CSF v11 Certification Criteria."

Note what the AWS sentence scopes: specific services, against a specific CSF version. Neither of those is a permanent property of the account you happen to have.

HITRUST also claims on the same page that "No other framework provides this capability." Treat that as positioning rather than a fact you rely on. Control inheritance in substance, if not under that name, is what a SOC 2 carve-out and a set of complementary subservice organisation controls do, and what the shared responsibility models published by every major cloud provider describe. What is genuinely distinctive is that HITRUST operationalises it inside the assessment platform rather than leaving it to narrative in a report.

The 70 to 85 percent figure, and the conditional attached to it

Two things about that number deserve stating before it lands in anyone's business case.

The first is what it is not. HITRUST publishes no method behind it: no sample, no distribution, no definition of which assessment type or CSF version produced it. It is a marketing figure on a page selling a program, phrased as "as much as", which is the phrasing of a ceiling. We would not put it in a budget, and we would push back on any consultancy that did.

The second is the conditional. AWS's formulation is not "customers inherit"; it is that customers can inherit "provided that customers use only HITRUST-certified services and apply the controls detailed in the HITRUST Shared Responsibility Matrix". In our experience the first half of that conditional is the expensive one. Real architectures accrete: a managed service adopted for one feature, a regional service used by one team, a preview capability that quietly went to production. Each one that sits outside the certified set is a set of requirements that comes back to you.

So the planning question is not "how much can we inherit". It is "which of our running services are inside the certified set, and what does it cost to move or re-scope the ones that are not". That question has an answer you can compute today, and it is worth computing before anyone quotes you a percentage.

Internal inheritance is the part nobody markets

The cloud story gets the attention because it is a bigger number. The internal story is the one that compounds.

HITRUST lists your organisation's existing HITRUST Validated or Certified Assessments as an inheritance source. For a company that certifies a platform and then needs coverage for a second product, a second environment or a subsidiary, that is the difference between two full assessments and one plus a delta. It is the same economics we describe in reusing compliance evidence across frameworks, applied within a single framework instead of across several.

The practical consequence runs backwards into how you scope your first assessment. A first assessment drawn tightly around one product produces less inheritable material for the second than one scoped around the shared platform underneath both. That is a decision made at scoping time, months before anyone thinks about inheritance, and it is very hard to unwind afterwards.

The Shared Responsibility Matrix is the actual artifact

Underneath the marketing, the object that does the work is the matrix. HITRUST publishes downloadable Shared Responsibility Matrices for cloud providers and platforms, along with what it describes as a free, easy-to-use baseline template for organisations without a published provider matrix.

A matrix is a control-by-control allocation: which party owns the control fully, which is shared, and what the customer must do for the shared ones. AWS's page directs customers to download a matrix to determine which controls are inheritable rather than publishing a number, which is the correct answer and the less satisfying one.

Two working notes. Use the provider's published matrix rather than a reconstruction, because a matrix you built yourself is an assertion and a published one is a reference. And where you use a vendor that publishes no matrix, the baseline template plus a signed statement from that vendor is the fallback, and it is materially weaker; expect it to be tested.

Inheriting a control does not move the risk

This is the sentence to take into your next architecture review.

Inheritance moves the evidence burden. It does not move accountability to your customer, your regulator, or the individuals whose data you hold. When a health plan asks who is responsible for encryption of the data you hold about their members, "our cloud provider is HITRUST certified" is a supporting fact, not an answer. You selected the service, you configured it, and you are the party in the contract.

The allocation in a matrix is also conditional on configuration. A provider owning the physical and hypervisor layers of a storage service says nothing about whether you enabled encryption with a customer-managed key, restricted the bucket, or turned on the logging your own requirement depends on. Every shared line in a matrix is a control you still have to operate, and the customer half of a shared control is exactly where assessments find gaps. Our vendor risk management guide covers the general version of this failure, and it is not specific to HITRUST.

What HITRUST's public pages do not tell you

An honest accounting of the gaps, because the alternative is inventing detail.

HITRUST's inheritance page does not describe how an inheritance request is raised, reviewed or approved, whether a providing organisation can decline, or what happens when a provider's certification lapses mid-assessment. It does not state whether or to what extent an authorised external assessor must independently validate inherited requirement statements. AWS's page defers on the same point, telling customers to refer to HITRUST for guidance on how to initiate an inheritance request. We fetched both pages and neither answers it, so we are not going to describe a workflow we have not seen documented.

The same page closes with a claim of a "99.62% breach-free rate among HITRUST-certified environments". No population, no time window and no method accompany it. A breach-free rate over an unstated denominator is not a statistic you can act on, and certified organisations are not a random sample of organisations, so even a true figure would not support the causal reading it invites. We mention it because you will see it quoted, and because a program worth buying does not need it.

One more limit that is not HITRUST's doing but is ours: a HITRUST validated assessment is performed by a HITRUST Authorized External Assessor and reviewed by HITRUST. A readiness firm cannot certify you, and we cannot certify you. Any firm offering to both close your gaps and certify the result is worth a direct question about how it separates those roles.

Where Top Floor fits

Inheritance planning is scoping work, and scoping is where our HITRUST practice does most of its useful work: mapping which of your running services sit inside a provider's certified set, pulling the published matrices, allocating the shared lines to owners, and identifying the requirements that come back to you because of an architectural choice nobody revisited.

The underlying Security Rule obligations usually sit alongside it under our HIPAA practice, and we have written before about why HIPAA certification does not exist as a thing you can buy, which is part of why HITRUST fills that space in healthcare procurement. The continuing programme version runs under Compliance as a Service.

We do readiness. We are not a HITRUST Authorized External Assessor and we do not issue certifications.

How to decide this week

Pull the service inventory for the environment you intend to certify and mark each service as inside or outside your provider's HITRUST-certified set. That one list turns the inheritance question from a percentage into an engineering decision, and it is the artifact an assessor will ask for anyway.

Download your provider's published Shared Responsibility Matrix and read the shared lines rather than the provider-owned ones. The provider-owned lines are the good news and they take care of themselves. The shared lines are your assessment.

If you already hold a HITRUST assessment for another environment, ask before anything else whether the new scope can sit on the same certified platform. That question changes the size of the engagement more than any negotiation with an assessor will.

Frequently asked questions

How much can you inherit in a HITRUST assessment?

HITRUST states on its Shared Responsibility and Inheritance Program page that organisations can inherit as much as 70 to 85 percent of requirements from participating cloud service providers. That is HITRUST's own figure for its own program, published without a method, sample or definition of assessment type, and phrased as a ceiling. AWS conditions inheritance on using only HITRUST-certified services and applying the Shared Responsibility Matrix, which is why real percentages fall below the ceiling: services outside the certified set return their requirements to you.

What can HITRUST controls be inherited from?

HITRUST names three sources: vendors, major cloud service providers holding HITRUST certifications, and your own organisation's existing HITRUST Validated or Certified Assessments. The third is the one most often overlooked. A company certifying a second product or environment on a platform it has already certified can inherit internally, which is why the scope you choose for a first assessment materially affects the cost of the second.

Does inheriting a control mean our cloud provider is responsible for it?

No. Inheritance moves the evidence burden, not the accountability. You selected the service, you configured it, and you are the party in the contract with your customer. Matrices also allocate many controls as shared rather than provider-owned, and the customer half of a shared control (encryption configuration, access restrictions, logging) is where assessments most often find gaps. Treat a matrix as a work list, not a transfer of responsibility.

Can our readiness consultant certify our HITRUST assessment?

No. A HITRUST validated assessment must be performed by a HITRUST Authorized External Assessor and is then reviewed by HITRUST. Readiness firms, including Top Floor, prepare the scope, close gaps, assemble evidence and coordinate with the assessor, but cannot issue the certification. If a firm offers to do both halves, ask directly how it separates remediation from assessment, because the answer determines what the certificate is worth to the customer who asked for it.