If your product runs entirely in a public cloud, a large part of a HITRUST assessment concerns things you do not operate. You do not badge people into the data center. You do not replace failed disks or maintain the hypervisor. Your cloud provider does.
HITRUST has a mechanism for this: inheritance. A provider that has its own HITRUST assessment can make requirement statements available for you to inherit, so your assessment carries their tested result instead of asking you to prove something you cannot see.
Inheritance can save real effort. It can also go wrong in ways that only show up at quality assurance. This article explains how it works, where its limits are, and how to use it without losing scores.
How inheritance works
Inheritance runs through HITRUST's Shared Responsibility and Inheritance Program, inside MyCSF.
A provider completes a HITRUST validated assessment that covers the services you use, and publishes requirement statements as available for inheritance.
You identify which of your requirement statements depend on that provider, in whole or in part, for the systems in your scope.
You submit inheritance requests in MyCSF against the provider's assessment.
The provider approves or declines each request. Approved requests bring the provider's scores into your assessment for those requirement statements.
Your assessor evaluates whether the inheritance is appropriate for your scope, and HITRUST reviews the result at quality assurance.
The key point is that inheritance is a relationship between two HITRUST assessments. A provider's attestation report under another framework can be useful evidence, but it is not inheritance in HITRUST's sense. If a provider has no HITRUST assessment, ask your assessor how HITRUST's current rules let them consider other evidence for the requirements that provider performs.
Full versus shared responsibility
Not every requirement your provider touches is theirs alone. HITRUST distinguishes between two situations.
Fully inherited
The provider performs the requirement entirely, for the services you use, and there is nothing for you to do. Physical security of the data centers that host your workloads is the classic example for a cloud-only company. Badge access, visitor logs, environmental controls and media destruction in those facilities belong to the provider.
Shared, or partially inherited
The provider performs part of the requirement and you perform the rest. Both halves are needed for the requirement to be met. Most of the technical requirements in a cloud environment fall here.
Encryption is a good illustration. The provider may supply encryption capabilities and manage the underlying key infrastructure. You decide whether encryption is turned on, for which resources, with which keys and under which access policies. Inheriting the provider's half tells your assessor nothing about yours.
Using the provider's shared responsibility matrix
Some large cloud providers publish a HITRUST shared responsibility matrix. It lists requirement statements and indicates, for their services, which are the provider's responsibility, which are the customer's and which are shared. HITRUST also publishes guidance and a template for these matrices.
Treat the matrix as a starting point, not an answer:
Check the services, not the brand. A matrix covers specific services that were in the provider's assessment scope. If you use a service that was not in scope, you cannot inherit for it.
Check the regions or environments if the provider's assessment scope is limited to some of them.
Map to your own scope. The matrix tells you what the provider does in general. You still have to say which of your systems run on which services.
Read the customer column carefully. It is effectively a list of controls you need to own and evidence.
What you cannot inherit
Some things stay with you whatever your hosting model:
Your policies and procedures for the parts of a requirement you perform. In an r2, policy and procedure are scored levels, so your side needs both. Our article on r2 maturity scoring explains why documentation weighs on the result.
Configuration of the services you use. Identity and access policies, network rules, logging configuration, encryption settings and backup schedules are yours.
Your workforce and endpoints. Hiring, training, offboarding and the laptops your engineers use are outside any cloud provider's assessment.
Requirements on other providers. Your identity provider, code host and monitoring tools each need their own treatment. Inheritance from one provider does not extend to the others.
Getting the timing right
Inheritance depends on the provider's assessment being valid at the right times. Two checks belong in your plan.
Before fieldwork, confirm the provider's assessment is current and covers the services you use. Submit inheritance requests early. Approval is a manual step on the provider's side, and a pending request does not help you during fieldwork.
Through your certification period, keep an eye on the provider's certification. Your r2 runs for two years and the provider's cycle will not line up with yours. If you are preparing for an interim assessment or a renewal, confirm that what you inherited is still backed by a valid assessment.
A worked example
Say a 40-person SaaS company runs its product on a single public cloud, stores protected health information in a managed database and has no servers of its own. A hypothetical inheritance plan might look like this:
Full inheritance for data center physical and environmental requirements covering the provider's facilities.
Shared inheritance for encryption at rest, where the provider supplies the capability and the company shows that every in-scope database and storage bucket has encryption enabled with keys it controls.
Shared inheritance for infrastructure availability and backups, where the provider operates the underlying platform and the company shows its backup configuration and restore tests.
No inheritance for access reviews, security training, incident response and endpoint protection, which the company performs entirely itself.
The company documents its side of each shared requirement as it would any other control. It keeps the provider's matrix with the assessment file so the assessor can see where each line came from.
What your assessor will want to see
Inheritance reduces testing, but it does not remove the assessor's need to understand your environment. Expect to show:
- Not done:
A list of the provider's services you use for in-scope systems, ideally exported from your cloud account rather than written from memory.
- Not done:
The provider's matrix, or equivalent, showing how each inherited requirement statement is split.
- Not done:
Your mapping of in-scope systems to those services.
- Not done:
For each shared requirement, evidence of your portion: configuration exports, policies, procedures and records of the control operating.
The first item catches more problems than any other. A team that believes it uses four services often finds a fifth, added by an engineer for a short project and never removed.
Common mistakes
Requesting inheritance for everything the provider touches. Over-claiming invites questions at QA and can cost more time than it saves.
Not checking the provider's scope. A requirement inherited for a service that was not in the provider's assessment will not stand.
Leaving your side undocumented. For shared requirements, the provider's score covers only their portion.
Forgetting other service providers. The cloud is usually the biggest inheritance source, not the only dependency.
If you are still settling which assessment to pursue, start with our e1, i1 and r2 comparison. The HITRUST framework page summarizes how the CSF fits with the other frameworks you may run.
How TrustLynce helps
TrustLynce keeps a vendor inventory with risk tiers, reviews and reassessment dates, so you know when a provider's assessment is due to lapse. Evidence collection gathers records of your side of shared requirements, such as encryption and backup configuration, from your cloud accounts on a schedule.