How much HITRUST inheritance from a certified cloud provider can you expect?
When a customer or contract requires HITRUST and your platform runs on a certified cloud provider, the first question is how much of the work the provider already covers. HITRUST says organizations can inherit as much as 70% to 85% of requirements in HITRUST assessments from participating cloud service providers. That range is an upper bound across the market, not a promise for your environment. The exact share depends on the provider's Shared Responsibility Matrix (SRM) and on what you have scoped into your own assessment, so treat the range as a starting hypothesis to test against the matrix, not a figure to put in a budget.
The division of labor stays fixed regardless of how much you inherit. Your organization owns its controls and decides how each one is operated, evidenced and scoped. An implementation partner such as DeployOpen can prepare your systems, configuration and evidence for review, but it does not certify anything. Only an Authorized HITRUST External Assessor can perform the validated assessment, and HITRUST performs its own quality assurance before it issues a report. Inheritance changes which requirements the assessor tests in your environment. It does not change who signs the result.
Before you plan around any percentage, do three checks. Pull the provider's SRM for the services you actually use, since HITRUST publishes downloadable matrices for major providers and a baseline template. Map each requirement to the provider's side or your side, and confirm the provider's certification covers the specific services, regions and accounts in your design. Then ask your assessor how they will treat any gap between the matrix and your architecture. The HITRUST Shared Responsibility and Inheritance Program page is the natural starting point for locating those matrices.
Which domains inherit well and which stay with you
HITRUST's worked example from Oracle Cloud Infrastructure shows that inheritance follows the layer of the stack. Physical facilities transfer almost entirely, while endpoints and compute configuration stay with the platform operator. Use these examples to frame your own review, then confirm each domain against the provider's own shared responsibility matrix.
Physical and environmental security
In HITRUST's OCI example, this domain is highly inheritable because the cloud provider fully manages data center security, biometric access, HVAC and redundant power. Your part is limited to confirming that the provider's certification covers the regions and services you run in, and that the matrix assigns these requirements to the provider. Ask whether the provider's HITRUST scope names the specific facilities you depend on, since a broad statement about the cloud is not enough to inherit against.
Network protection
The same example rates network protection as moderately inheritable. The provider secures backbone networking and DDoS protection, but you still configure your own virtual networks, security groups and web application firewall. Expect the split to fall through the middle of the domain, so each requirement needs a clear owner in the matrix. Review your firewall rules, segmentation and WAF policies yourself, because the provider's certification does not cover how you configured them.
Endpoint protection
HITRUST's example rates endpoint protection as only slightly inheritable. You still run endpoint detection and response, patching and mobile device management, and you configure the compute workloads that run on the platform. Treat this domain as yours from the start of readiness work. Confirm that no part of your endpoint or workload tooling is assumed to come from the provider's certified scope.
Check the provider's own matrix
These three examples come from one provider's worked example and are illustrative, not a guarantee for your platform. Each provider publishes its own shared responsibility matrix, and the split for every domain can differ. Read the matrix line by line against your architecture, mark each requirement as provider, shared or customer, and keep that record with your assessment evidence. A baseline template can help you structure the review.
What a cloud provider's HITRUST certification does not cover
A provider's HITRUST certification covers the services the provider runs, not the platform you build on them. HITRUST can certify back-end infrastructure, and a cloud provider certifies the services it offers. Each customer certifies the platform it operates on those services. Applications whose instances sit outside the entity's control, such as mobile apps, cannot be certified by HITRUST at all, so they need their own treatment in your assessment regardless of how strong the provider's report is. Before you plan inheritance, treat the provider's certificate as a statement about its managed layer only.
What stays with you is usually the part that produces the most findings. That includes the applications you write and deploy, identity configuration such as role assignments, MFA enforcement and privileged access settings in your tenancy, and the data classification decisions that determine which controls apply to which stores. It also includes logging and monitoring of your own workloads, meaning which audit logs you enable, where they are retained and who reviews them, and the operational processes that run the platform day to day, such as change approval, incident response and access reviews. A provider can supply the logging service, but it cannot decide what your workloads log.
Confirm these boundaries in two places before the assessment starts. First, read the provider's Shared Responsibility Matrix for the specific services you use, not only the provider-level summary, and mark every requirement it assigns to the customer. Second, map that list against your own environment, including any third-party tools, self-managed components and sub-accounts that sit outside the provider's certified services. Any gap you find is yours to close or to address with an assessor, and it should be recorded in your scope statement before inheritance requests are filed.
How incubation applies to inherited controls
This sequence shows which inherited controls skip the 90-day incubation wait and which still need their own run time before your validated assessment. It ends with a documented record that an External Assessor can test.
Confirm the provider's control history
Start by asking the provider in writing when each control it performs for the services you use began operating, and whether that operation has run for at least 90 days. The provider can show this through operating history for other customers or through an existing report that covers the control. Your platform team reviews the answer, and the output is a dated control history list that names each control and its start date. Keep this list with the inheritance request so the assessor can see where the 90-day condition is met.
Map inherited controls to the provider's SRM
Take the provider's Shared Responsibility Matrix and the baseline SRM template, then mark which requirements the provider covers, which you share, and which remain entirely yours. Your compliance lead and the platform owner complete this together, because a matrix entry only counts once your own configuration matches it. The output is a mapping sheet that lists each inherited requirement next to the provider's responsibility and your responsibility. An SRM describes responsibilities but does not prove that a control operates, so the mapping is a planning record, not evidence.
Document where the provider's report is relied on
For each control you inherit or rely on through a provider's existing report, record the report name, period covered, scope, and the specific control references it supports. Confirm that the report's scope includes the services your platform actually uses, not only the provider's wider offering. The output is a reliance register that the External Assessor can read alongside the mapping sheet. Note any gap between the report's period and your assessment window, because that gap decides whether the provider's operation can be counted without further wait.
Identify controls still needing incubation
Go through the mapping sheet and flag every control that you perform yourself, and every provider control that lacks either 90 days of operation or a relied-upon report. Your engineers and security lead own this review. The output is a list of controls that still need their own incubation period, each with the date its operation started or is planned to start. Treat this list as the critical path for readiness, since these controls can only be credited once they have run long enough.
Start and evidence your own incubation
Enable each flagged control in your environment and keep records from the first day it operates. Typical records include configuration snapshots, change tickets, access review outputs, and alert or log samples that show the control working. Your control owners maintain these records, and the security team checks them monthly against the control definition. The output is a continuous operating record per control that proves the control ran consistently across the incubation period.
Agree the assessment window with the assessor
Before fieldwork, confirm with your External Assessor which controls they will test in the validated assessment, and how the fieldwork window fits around the incubation dates. The HITRUST Assessment Handbook caps the assessor's validated fieldwork window at 90 days for e1, i1 and r2. This cap governs how long the assessor takes to test, not how long a control must run before it counts. The output is a written agreement on the fieldwork dates and the controls each party will sample.
Hand over the complete inheritance record
Assemble the control history list, mapping sheet, reliance register, incubation records and assessor agreement into one package and send it with your inheritance request. Your compliance lead owns the package, and the External Assessor confirms it is complete before testing begins. The output is a single traceable record showing, for each inherited control, why the 90-day condition is met or which controls still rely on your own run time. Keep this record current, because a change to the provider's scope or your environment can affect what you are allowed to inherit.
What changes by environment: single cloud, multi-cloud, and hybrid
When the whole platform runs on one cloud provider that holds its own HITRUST certification, the inheritance path is the most direct. The provider's validated results cover the services it operates, and your assessment can draw on them for the requirements that sit in its scope. Your team still owns everything it configures and runs on top of those services, so the remaining work is concentrated in the customer-owned layers. Plan the assessment around the provider's shared responsibility matrix for that platform and confirm which items it maps to each requirement.
- Provider-owned layers: Data center security, physical access, environmental controls and backbone networking usually sit with the provider and are the strongest candidates for inheritance.
- Customer-owned configuration: Virtual networks, security groups, identity policies, encryption settings and workload hardening remain your responsibility and need direct evidence.
- Operating system and application layers: Patching, endpoint protection, application security and logging of your own workloads generally stay with you.
- Provider scope limits: Confirm which services and regions are covered by the provider's certification, since services outside that scope are not inherited.
- Recertification alignment: Track the provider's certification dates so that inherited results do not lapse during your own assessment window.
Before relying on the provider, check that the certified services match the exact services your platform uses.
When a platform spans two or more cloud providers, each provider's shared responsibility matrix has to be mapped separately, because each one draws the line between provider and customer in a different place. Inheritance is then applied per provider and per service, not across the whole estate at once. Gaps tend to appear where no provider's certified scope overlaps with the controls you need, particularly for cross-cloud identity, logging, key management and network connections that you build yourself.
- Separate matrices: Map each provider's shared responsibility matrix to your requirements independently, then compare the results.
- Overlap analysis: Identify requirements that more than one provider covers, and decide which provider's results you will use as the source for each.
- Cross-cloud gaps: Look for controls that no provider owns, such as consistent policy enforcement, centralized logging and the connections between environments.
- Inconsistent scope: Providers may certify different services or regions, so a service you use in one cloud may not have inherited coverage at all.
- Coordinated evidence: Gather evidence from each environment in a consistent format so the External Assessor can trace each requirement to a single source.
Ask each provider to confirm in writing which of its services and regions are covered by its current certification.
A hybrid platform combines cloud services with on-premises or colocated components. Those on-premises or colocated parts receive nothing from a cloud provider's certification, because the provider does not operate or control them. Every component outside the provider's scope needs its own evidence and, where the assessment requires it, direct testing by the External Assessor. Your facilities, hardware, local networks and any colocation arrangements are all part of your own scope.
- No inheritance across the boundary: A cloud provider's results do not extend to your data center racks, local servers or colocated cages.
- Physical controls on premises: Access control, environmental protection and power for on-premises rooms must be evidenced by you or by the colocation operator under its own report.
- Connectivity between sites: Links between cloud and on-premises environments are a shared boundary that needs explicit ownership and evidence on both sides.
- Colocation providers: A colocation operator may hold its own assessment or audit report, which should be checked for age, scope and relevance before it is relied upon.
- Direct testing needs: Plan for direct testing of on-premises components early, since those controls are not covered by any inherited result.
Confirm the boundary of each assessed environment in writing before fieldwork, so every component has a clearly named owner and evidence source.
What to verify before you request inheritance
Inheritance only works when the provider's certification, scope and report actually match what your platform runs and when your assessment takes place. Each check below should be confirmed in writing with the provider and your External Assessor before you submit an inheritance request.
Confirm current certification and scope
Ask the provider for its current HITRUST certification, its assessment type, its validity dates and the exact scope boundary it covers. A certificate for one region, one product line or one set of services does not extend to everything the provider sells. Confirm that the certified scope includes the infrastructure your platform depends on, and that the certification is still in force on the dates your own assessment will run.
Obtain the right SRM
Request the provider-specific Shared Responsibility Matrix if one is published, and use HITRUST's baseline SRM template only where no provider-specific version exists. The matrix shows which requirements the provider covers and which remain yours. Read it against your architecture, not against the marketing summary, and treat it as a map of responsibilities rather than evidence that any control works.
Match services to certified scope
List every cloud service your platform uses, including managed databases, container services, load balancers, identity services and backup targets, and check each one against the provider's certified scope. Services outside the certified boundary cannot be inherited, and your team will have to evidence those controls directly. Ask the provider to confirm service by service, because a broad statement that the platform is certified can hide gaps.
Check report currency against your window
Compare the dates of the provider's certification or supporting report with the period your assessment covers. Under HITRUST's rules, a control performed by a service provider needs no separate 90-day run period only when the provider shows it has operated for at least 90 days, or when you inherit or rely on an existing report. Confirm that the report is current when your fieldwork starts, and plan for a renewal of the provider's certification that may fall inside your assessment window.
Identify controls the provider does not perform
Go through the SRM and mark every requirement the provider leaves to you. In HITRUST's Oracle Cloud Infrastructure example, endpoint protection stays largely with the customer, who runs EDR, patching and MDM, and network protection is shared, with the customer configuring its own virtual networks, security groups and web application firewall. Use that pattern to list your own endpoint, identity, configuration and application controls, and assign an owner to each one.
Agree how inherited results are documented
Before fieldwork starts, agree with your External Assessor which inherited scores you will use, which evidence the assessor will accept from the provider, and how the inheritance will appear in your assessment record. Confirm the request timing and the approval steps with the provider. Only the independent assessor and HITRUST decide whether inherited results are accepted, so settle these points early rather than during quality review.
Who owns the controls, who prepares the evidence, who validates it
The organization owns its controls. Running on a HITRUST-certified cloud platform does not move responsibility for the controls the organization operates. The organization still decides how identities are granted, how endpoints are secured, how virtual networks and security groups are configured, how workloads are patched and how incidents are handled. A provider's certification can cover the services it runs, but each customer certifies the platform it builds and operates on those services. Before any inheritance request, the organization should confirm which requirement statements belong to the provider's scope and which fall to its own team, and name an owner for every remaining statement.
DeployOpen or another implementation partner works on the systems and the paperwork around them. A partner can configure the customer-side settings, map the provider's Shared Responsibility Matrix to the organization's scope, prepare the evidence the assessor will sample, and document where inherited results apply. This work is preparation only. DeployOpen does not issue HITRUST reports or certificates, and hiring a partner does not guarantee a passing result. The partner's written scope should state which deliverables it produces, which items stay with the organization, and what it will not do, such as attesting that a control operates effectively.
Only an Authorized HITRUST External Assessor performs the validated assessment, and HITRUST performs central quality assurance before it issues the report. The assessor decides which inherited results it accepts, tests the customer-side controls and samples evidence within the assessment fieldwork window. Before engaging an assessor, the organization should confirm that the firm is on HITRUST's list of Authorized External Assessors, ask how it will handle inheritance requests from the provider, and agree in writing who gathers the provider's documentation. Organizations that treat a partner's readiness work as validation will find the gap only when the assessor reports it.
Questions buyers ask about inheriting HITRUST controls from a cloud provider
How much of a HITRUST assessment can we inherit from a cloud provider?
HITRUST says organizations can inherit as much as 70% to 85% of requirements in HITRUST assessments from participating cloud service providers, according to HITRUST's Shared Responsibility and Inheritance Program. That range is a ceiling for well-matched providers, not a promise for your platform. The share you actually inherit depends on which services you run on the provider, how much of the stack you operate yourself (operating systems, applications, endpoints, identity configuration) and whether the provider's assessment covers the services in your scope. Ask the provider for its current shared responsibility matrix and map each requirement statement to a provider-covered service, a customer-operated control or a split. Confirm the result with your External Assessor before you plan evidence work.
Does a cloud provider's HITRUST certification cover our whole platform?
No. A cloud provider's HITRUST certification covers the services it offers and its own operation of them, while you certify the platform you build and run on those services. HITRUST's guidance is that a provider certifies the services it offers, and each customer certifies the platform it operates on them. Applications whose instances sit outside your control, such as mobile apps, are not covered by the back-end infrastructure certification. Your application code, configuration, access management, endpoints and data handling remain in your scope. Confirm with the provider exactly which services and regions its certification names, and confirm with your assessor which of your components fall outside that boundary.
What evidence must we still produce ourselves when we inherit controls?
You must still produce evidence for every control you own, and for the configuration you apply to inherited services. Inheritance reuses a provider's validated results, but it does not remove your duty to show that your side works. Typical customer-side evidence includes:
- Configuration exports for virtual networks, security groups and web application firewall rules
- Identity and access records, including privileged account reviews and MFA enforcement
- Patch, endpoint detection and device management reports for compute you operate
- Change records, logging and monitoring outputs, and backup restore tests
- Your own policies, risk assessments and incident records
Ask your assessor which evidence items they will sample, and which provider documents they will accept as proof of the inherited portion.
Do inherited controls need an incubation period?
Usually the incubation rules apply to controls you operate, while a provider's control can avoid the wait in some cases. HITRUST's Handbook says a control performed by a service provider does not need the 90-day wait if the provider shows it has run for at least 90 days, for example for other customers, or if you inherit or rely on the provider's existing report. Controls you implement or change yourself still need time to operate before assessment. Plan for your own controls to show a sustained operating history, and confirm with your assessor how they will count the provider's period and whether a recent platform migration resets your clock.
How long can the fieldwork for an inherited assessment take?
The assessor's validated assessment fieldwork window is at most 90 days for e1, i1 and r2 assessments, according to the HITRUST Assessment Handbook version 1.1. That limit applies to the fieldwork period, not to your full preparation. Inheritance can shorten the testing you need from the assessor because provider results are reused, but preparation time for your own controls, evidence collection and corrective work still drives the overall schedule. Ask your assessor to confirm the fieldwork dates, the list of inherited requirements they will verify, and the evidence they will need before the window opens.
Can we handle HITRUST inheritance without outside help?
Many teams can do the internal work themselves, but the assessment itself must be run by an Authorized HITRUST External Assessor organization. Only those assessors perform the validated assessments submitted for certification, and HITRUST performs central quality assurance before issuing reports. Internal work includes reading the provider's matrix, mapping requirements, configuring your side, collecting evidence and keeping it current. Outside help can prepare systems and evidence under a written, fixed scope, but it cannot issue the HITRUST report. Before you decide, confirm with the provider which inheritance requests it accepts, and ask your assessor to review your mapping early so gaps surface before fieldwork.
Where to go next in the inheritance process
Read the mechanics before you request anything. The HITRUST page on how inheritance works explains how validated scores from a provider's or your own assessment flow into yours, which source assessments qualify, how full and partial inheritance differ, and where inheritance is not allowed. Then read the page on shared responsibility matrices, which explains what a provider's SRM says about the requirements it can cover, how provider-specific and baseline SRMs feed an inheritance request, and why an SRM is not evidence on its own. Pull the SRM for each cloud service in your scope and mark every requirement the provider covers, every requirement you cover, and every requirement that is split between you. Those marks become your starting inventory for the request. You can read the program details on the HITRUST Shared Responsibility and Inheritance Program page.
Then read the page on carve-outs and inheritance, because that choice comes before any inheritance work starts. It covers when a cloud or service provider can be carved out of an e1 or i1, why the r2 handles providers differently, and when inheritance, reliance on a provider's report or direct testing is the better route. Make that decision provider by provider and record it in your scope before your External Assessor begins fieldwork. A provider you planned to inherit from can end up tested directly if its evidence does not meet the rules, so build a fallback for each one. Confirm the current rules with your assessor, since the handbook and CSF version in use determine them. Your next action is a short register listing each provider, the route chosen, the reason and the evidence you hold, which you can review with the assessor at scoping.
How DeployOpen prepares a self-hosted platform for inherited HITRUST controls
DeployOpen plans, implements and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. Where your cloud provider holds its own HITRUST certification, we prepare the platform layer you still own so that inherited requirements are backed by clear, testable evidence. Independent assessors, not DeployOpen, decide what is accepted.
How we scope
- We agree a written scope that lists which requirements your provider covers and which remain your responsibility.
- We map the provider's shared responsibility matrix against your platform components so each gap is named before work starts.
- Engagements are fixed-scope, with scope, deliverables and timelines confirmed in writing before any work begins.
How we build
- We configure the customer-side controls the provider does not cover, such as endpoint protection, virtual networks and workload configuration.
- We harden and integrate the self-hosted platform components inside your environment and record each configuration decision.
- We run security testing against the platform so that test results can be reviewed alongside the inherited control claims.
How we hand over
- We deliver documentation that ties each customer-side control to the evidence an assessor will request.
- We agree evidence collection routines, so records are produced during operation rather than assembled before an assessment.
- We transfer runbooks and control documentation to your team, and you decide how the final assessment is commissioned.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- We can review changes to the platform or provider that could affect inherited control claims before they reach production.
- Ask us to confirm the scope of any retainer in writing, including how changes to the provider's certification are handled.
