If your product runs on AWS, Azure or Google Cloud, a large part of your HITRUST work may already be done by your cloud provider. HITRUST inheritance is how you get credit for it. Used well, it's the single biggest way to reduce the effort of a HITRUST assessment. Used carelessly, it's a common source of surprises late in the project.
This guide explains what inheritance is, how the Shared Responsibility Matrix works, what you can and can't inherit, how inheritance is requested in MyCSF, and the mistakes to avoid.
What HITRUST inheritance is
HITRUST's Shared Responsibility and Inheritance Program lets organizations inherit controls from certified cloud providers and vendors. If your provider has already had a control validated in its own HITRUST assessment, you can rely on that result for the parts of the control the provider performs, rather than having your assessor test it again.
HITRUST states organizations can inherit 70% to 85% of requirements from participating cloud service providers. That figure is HITRUST's, and it describes what's possible with participating providers. Your own share depends on your scope and on how much of your environment actually runs on those services.
The Shared Responsibility Matrix
Every cloud service splits security work between the provider and the customer. The provider secures the data centers and the underlying infrastructure. You secure what you build and run on top: your accounts, your applications, your data and your people.
HITRUST's Shared Responsibility Matrix sets that split out requirement by requirement. For each HITRUST requirement, it shows whether the provider is fully responsible, you're fully responsible, or the responsibility is shared. That's the starting point for deciding what you can inherit.
What you can and can't inherit
The general pattern is simple: you can inherit what the provider does, and you can't inherit what you do.
| Usually inheritable from the provider | Usually your responsibility | Often shared |
|---|---|---|
| Physical security of data centers | Access management for your accounts and applications | Encryption (provider offers it, you configure and use it) |
| Environmental controls such as power and cooling | Application security and secure development | Logging (provider supplies logs, you collect and review them) |
| Underlying hardware and network infrastructure | Your policies and procedures | Backups (provider supplies the service, you set and test it) |
| The provider's own operations staff and processes | Your staff training and HR controls | Network security settings in your own cloud accounts |
Shared controls are where the work is. You can inherit the provider's part, but your part still has to be in place and evidenced.
How inheritance is requested in MyCSF
HITRUST assessments are managed in MyCSF, and that's where inheritance happens. At a high level:
- Scope your assessment so it lists the cloud services your in-scope systems actually use.
- Identify the inheritable requirements using your provider's published HITRUST inheritance information and the Shared Responsibility Matrix.
- Submit inheritance requests in MyCSF for the requirements, or parts of requirements, you want to inherit.
- Document your own side of every shared requirement, with your own policies and evidence.
Your assessor reviews the inherited and non-inherited parts as part of the validated assessment.
Common mistakes
- Assuming full inheritance. Hosting on a certified cloud provider doesn't make you certified. The 70% to 85% figure is what HITRUST says is possible with participating providers; it isn't automatic, and it doesn't cover your own controls.
- Not documenting shared controls. If a requirement is shared, you need evidence for your part. Teams often inherit the provider's half and forget to document their own.
- Inheriting for services you don't use. Inheritance only applies to the provider services in your scope. Map it to the services your systems actually run on.
- Leaving it until the end. Inheritance changes how much testing your assessor needs to do. Map it early, during scoping, not just before fieldwork.
How inheritance fits with your assessment choice
Inheritance helps whichever assessment your customer asks for. It's especially useful for startups going for an e1, where infrastructure controls can be a large part of a small scope, and for r2 projects, where the number of requirements is largest. Not sure which assessment you need? Try our HITRUST assessment chooser. For the full process, read how to get HITRUST certification step by step.
A worked example: access to your cloud console
Take one shared area to see how the split works in practice: access to the cloud accounts that run your product.
- The provider's part: it runs and secures the identity service itself, the hardware it runs on and the data centers behind it. You can inherit that.
- Your part: you decide who gets an account, turn on multi-factor authentication, remove people who leave and review access on a schedule. None of that can be inherited, because only you can do it.
Your assessment needs both halves. The provider's half comes from inheritance. Your half comes from your own policy, your access review records and your offboarding tickets.
Questions to ask before you count on inheritance
Before you build your plan around inheritance, get clear answers to these:
- Does our cloud provider take part in HITRUST's inheritance program for the services we use?
- Which of our in-scope systems actually run on those services, and which run elsewhere?
- For each requirement, is it fully inheritable, partly inheritable or not inheritable at all?
- Who on our team owns our side of each shared requirement?
- Where will we keep the evidence for our side, and who will keep it current?
If you can't answer one of these yet, that's your next task. Clear answers early make the assessment much smoother.
How CyberWave GRC helps
At CyberWave GRC, inheritance mapping is a standard part of our HITRUST readiness work, alongside scoping, gap assessment, remediation guidance, policies, evidence and MyCSF setup. We map what you can inherit from your cloud provider, document your side of every shared requirement and keep the evidence organized in MyCSF.
The validated assessment is performed by Huduku AI, an independent HITRUST Authorized External Assessor we work with, and HITRUST performs quality assurance and issues the certification. Our team includes HITRUST CCSFP and CHQP certified practitioners. Start with a HITRUST readiness assessment or visit our HITRUST consulting page.