How does HITRUST inheritance work for your HITRUST assessment?
If a customer or contract now requires HITRUST, inheritance lets you reuse validated maturity scores from another active e1, i1 or r2 assessment, either a provider's (external inheritance) or your own earlier assessment (internal inheritance). The External Assessor then carries those scores into your assessment instead of retesting the same requirements. How much of the work this removes depends on how each requirement is split between you and the other party, not on a fixed percentage. Your organization still owns its controls, and the External Assessor validates every inherited score before it counts toward your result.
Each requirement falls into one of two situations. If the provider carries the whole requirement, full inheritance can apply. If responsibility is shared, partial inheritance applies instead, and each requirement receives a weight percentage backed by a written rationale that the assessor checks. Inheritance is not available where your organization has sole responsibility, authority and accountability for a control, and inherited scores cannot be edited by your team. Start by collecting the provider's current validated assessment, its scope statement and its Shared Responsibility Matrix, then map each requirement to the party that operates it. Confirm the provider's certification covers the services you actually use, since a certification for one product line does not reach another.
Timing matters because external requests go through the provider's MyCSF approval workflow, must be submitted no more than 30 days before fieldwork, and must be lodged before the 90-day fieldwork window closes. Each request also needs a valid business justification. Ask your External Assessor early which source assessments they will accept, and ask the provider how long its approvals take. Readiness or incomplete assessments can only be inherited into readiness work, not into a validated assessment, so confirm the provider's status before you plan your timeline. Ask the assessor and the provider to confirm these points in writing before you commit to a scope.
Full inheritance versus partial inheritance: which applies to a requirement?
Full inheritance applies only when a requirement is entirely outsourced to the provider. The provider owns the control, operates it and is accountable for it, and nothing in the control depends on your own people, processes or configuration. Under the HITRUST Assessment Handbook, full inheritance is the case where the inheriting organization takes the provider's validated score for that requirement without adding its own testing. Because the entire requirement sits with the provider, there is no weight split to document.
- Entirely outsourced: The provider performs the whole requirement, such as physical access controls within a data center it operates.
- Provider's validated result: The score must come from an active, eligible HITRUST validated assessment of the provider, requested through the provider's approval workflow.
- No partial reliance: If any part of the requirement remains with your team, full inheritance is not available for that requirement.
- Fixed scores: You cannot change an inherited score, so the provider's result stands as reported.
- Assessor validation: The External Assessor confirms that the provider's assessment covers the requirement and that the request was made in time.
Before you claim full inheritance, check the provider's Shared Responsibility Matrix and confirm with the provider, in writing, that the requirement is wholly theirs. Ask whether the provider's assessment scope includes the services you use.
Partial inheritance covers shared responsibility, where the provider and the organization each carry part of a requirement. The Handbook calls for a weight percentage per requirement, showing the share of the control that the provider's validated result covers, and a documented rationale that the External Assessor validates. The weight must match the split described in the provider's matrix and in your own configuration, and the assessor tests the rationale rather than accepting the percentage on its face.
- Weights per requirement: Each partially inherited requirement carries a percentage that reflects the provider's share of the control.
- Documented rationale: Write down which tasks the provider performs and which tasks your team performs, with the reason for the split.
- Assessor testing of your share: The part you keep must be tested directly, with evidence from your own environment.
- Matrix alignment: The rationale should reference the provider's SRM and your responsibility assignments, so the two line up.
- Consistent scope: The provider's assessment must cover the services that carry the shared requirement.
Build a requirement-level worksheet that lists each shared requirement, the weight, the rationale and the evidence for your share. Expect the assessor to ask for the configuration records, logs or tickets behind your portion.
Internal inheritance reuses results from your own active HITRUST e1, i1 or r2 validated assessment in a later assessment. The source can be an assessment of a different business unit, platform or environment that you operate, provided it is still active. The Handbook allows inheritance across CSF versions, so the earlier assessment does not need to match the current version. The inheriting assessment still needs its own validation, and the assessor must confirm that the source applies to the scope being assessed.
- Own active assessment: The source must be an active e1, i1 or r2 validated assessment of your organization.
- Cross-version reuse: Scores can be inherited across CSF versions, so you do not need to rebuild the evidence for each release.
- Scope match: The assessor checks that the source covers the same systems, processes and controls being inherited.
- Readiness limits: Readiness or incomplete assessments can only be inherited into readiness assessments, not validated ones.
- Unchanged source: The source result must still reflect the current state of the controls, so significant changes need review.
Confirm the source assessment's status, expiry date and scope with the External Assessor early. Changes to the environment since the source was validated are the most common point where internal reuse fails.
Whichever type applies, the External Assessor must be able to trace each inherited score to a valid source and confirm that the claim is correct for your scope. The assessor does not accept an inheritance claim based on a matrix or a verbal assurance alone. The evidence set is the link between the source assessment and your environment, and it is reviewed before HITRUST performs its central quality assurance.
- Request record: The approved external request in MyCSF, submitted within the timing window and with a valid business justification.
- Source report reference: The provider's or your own validated assessment, showing the active status and the requirements it covers.
- Matrix and rationale: The SRM extract, weight percentages and written rationale for each partial requirement.
- Your share's evidence: Configuration exports, access reviews, logs, change tickets or other records for requirements you retain.
- Scope statement: A clear description of the systems, locations and services the inherited results apply to.
Compare your evidence list with the assessor's request list early. Missing scope statements and unsupported weight percentages are common reasons for rework.
When and how to submit an external inheritance request
This sequence confirms that a provider's HITRUST assessment can be inherited, gets the request approved inside MyCSF with a valid business justification, and records the approved scores in your own assessment. Each step ends with a check you can verify before moving on.
Confirm the provider's assessment is active
Before anything else, confirm that the provider holds an active e1, i1 or r2 validated assessment that you can inherit from. Ask the provider for its current assessment status and the assessment type, and check the CSF version it was performed against. Inheritance works across CSF versions, but the source assessment must be active. Readiness assessments and incomplete assessments are not eligible for external inheritance. Those can only be inherited into other readiness assessments. The step is done when you hold written confirmation of the active status from the provider.
Agree the inheritance scope with the provider
Identify which requirement statements your provider's services cover, and which ones your organization still owns. Compare those against the provider's Shared Responsibility Matrix so both parties agree on what is outsourced and what is shared. This agreement defines which requirements will be requested as full inheritance and which as partial inheritance, and it sets up the rationale your External Assessor will later validate. The step is done when both parties have a shared list of requirements and responsibilities that they can each sign off.
Prepare the business justification
Write a business justification that explains why you are requesting inheritance and how the provider's validated results apply to your environment. Your assessor will check that this justification is valid, so it should describe the services in use, the relationship between your organization and the provider, and the requirements affected. Keep the justification consistent with the scope agreed in the previous step. The step is done when the justification is written, reviewed by your compliance lead, and ready to attach to the request.
Submit the request through MyCSF
Submit the external inheritance request through MyCSF's approval workflow, and send it to the provider for review. The request must be submitted no more than 30 days before fieldwork begins and before the 90-day fieldwork window ends. Confirm the dates with your External Assessor before you submit, because a late request can leave insufficient time for the provider to approve it. The step is done when MyCSF shows the request as submitted and assigned to the provider for approval.
Track the provider's approval decision
The provider reviews the request in MyCSF and approves or declines it. Monitor the request status during fieldwork and respond promptly to any questions from the provider. If the provider declines, you must test the affected requirements directly or agree a different route with your assessor. The step is done when the provider's approval appears in MyCSF with the scope it covers.
Record the approved scores in your assessment
Once approved, the inherited scores from the provider's validated assessment are linked to your own requirement statements. Confirm that each inherited score matches the approved scope, and that any partial inheritance carries the weight percentages and documented rationale the assessor will validate. Inherited scores cannot be changed by your organization, so any error must be raised with the provider and resolved through the workflow. The step is done when each inherited requirement shows its approved score in your assessment record.
Hand the record to your External Assessor
Provide your External Assessor with the approved request, the justification, the scope agreement, and the approved scores. The assessor validates the inheritance, including the rationale for partial inheritance, before the assessment is submitted for certification. Only an Authorized HITRUST External Assessor can perform this validation, and HITRUST performs quality assurance before issuing the report. The step is done when the assessor confirms the inherited scores are supported and records them in the validated assessment.
Where inheritance is not allowed
HITRUST limits inheritance to requirements that are genuinely shared or outsourced, and it blocks reuse where the entity carries the whole control or where the source result is not valid for the request. The four cases below are the ones assessors most often reject, and each one can be spotted early in scoping if you know what to look for.
Controls the entity fully owns
Inheritance may not be used where your organization has sole responsibility, authority and accountability for a control. Typical examples are access decisions for your own staff, the policies that govern your people, and business processes that run entirely inside your walls. During scoping, list each requirement and ask who decides, who operates and who answers to a regulator. If the answer is only your team, test it yourself and do not send an inheritance request for it.
Inherited scores you cannot edit
Scores you inherit from a provider's validated assessment are fixed. Your team cannot raise, lower or re-weight them in your own MyCSF record, even if your reading of the provider's evidence differs. Watch for pressure to change a provider's result to fit your gap analysis. The safe response is to document the disagreement, raise it with the provider and your External Assessor, and treat the inherited score as final for that assessment.
Readiness results used as validated
Readiness or incomplete assessments can be inherited only into other readiness assessments. A validated e1, i1 or r2 cannot take scores from a readiness report or from an assessment still in progress. Check the status and type of any source before you plan around it. If the provider's result is only readiness-level, plan to test those requirements directly, or ask the provider when a validated assessment will be complete.
Requests outside the timing window
External inheritance requests must go to the provider through MyCSF's approval workflow, and they must be submitted no more than 30 days before fieldwork and before the 90-day fieldwork window ends. A request filed earlier, or too late to be approved, leaves those requirements untested with no valid inherited result. Set the request date in your project plan, confirm the provider's approval turnaround in writing, and record the business justification so the request is complete when it is filed.
How much effort inheritance saves, according to HITRUST
HITRUST's 2024 data shows that inheritance is common and that External Assessors spent noticeably fewer hours on assessments that used it. According to the HITRUST 2025 Trust Report, 69% of r2, 67% of i1 and 60% of e1 validated assessments used external inheritance in 2024. External Assessors reported 14% fewer hours on r2 assessments, 23.4% fewer on i1 assessments and 9.1% fewer on e1 assessments that used inheritance. These figures are averages across assessments in the report. They describe what happened in the market, not what your assessment will cost or how long it will take.
HITRUST also says organizations can inherit 70% to 85% of requirements from participating cloud service providers, as stated on its Shared Responsibility and Inheritance Program page. That range is a ceiling for a well-matched provider, not a guarantee. The share you actually inherit depends on the provider's Shared Responsibility Matrix (SRM), which shows which requirements the provider's own validated assessment covers, and on your own scope. Requirements where you hold sole responsibility cannot be inherited, and shared requirements are only partially inherited. Before you estimate effort savings, map your environment against the provider's SRM and count the requirements that remain yours.
Treat the 2024 percentages as a question to put to your External Assessor and your provider, not as a budget line. Ask the assessor how many requirements they expect to rely on inherited results, how many they will test directly, and how the hours in their quote change with that split. Ask the provider which SRM version and which assessment scope it covers. The savings you see will reflect the fit between those two documents and the controls you run yourself.
Choosing between external, internal and partial inheritance
This table compares external full, external partial and internal inheritance on who owns the control, what the inheriting entity can change, what the assessor reviews and when each route fits. Read each row as a decision point: first confirm who is accountable for the control, then choose the route that matches that answer.
| Decision point | External full inheritance | External partial inheritance | Internal inheritance |
|---|---|---|---|
| Who owns the control | The provider owns the requirement entirely; the entity has no sole responsibility for it | Provider and entity share responsibility for the requirement | The entity itself, through an earlier or separate validated assessment of its own |
| Allowed when | The requirement is fully outsourced to the provider with an active provider assessment | Shared responsibility applies and the provider's scope covers part of the requirement | The entity holds an active e1, i1 or r2 result it can reuse for a later assessment |
| What the inheriting entity can change | Nothing; the inherited score cannot be altered by the inheriting entity | Only its own share, supported by a documented rationale and weight assigned to the requirement | Scores from its own validated assessment are reused as they stand, across CSF versions where permitted |
| Evidence the assessor reviews | The provider's active validated assessment and the approved inheritance request | The provider's assessment, the shared responsibility matrix, the weighting and the entity's own testing | The earlier validated assessment results and its active status at the time of request |
| Request route | Submitted to the provider through MyCSF's approval workflow with a business justification | Requested through the same provider workflow, with weights recorded per requirement | No external approval step; the entity's own assessment record is the basis |
| Where it does not fit | Any control where the entity keeps sole responsibility, authority or accountability | Requirements the entity controls alone, which must be tested directly | Readiness or incomplete assessments, which can only feed readiness assessments |
| Main takeaway | Smallest testing burden, but only for fully outsourced controls | Most common in practice; accuracy depends on clean weighting and rationale | Useful for reassessments, but the earlier result must still be active and eligible |
Mistakes that cause inherited scores to be rejected
Most rejected inheritance requests trace back to a few avoidable errors: confusing a responsibility matrix with evidence, overstating what a provider covers, and missing deadlines or lapsed source assessments. Each card below names one error, why it matters for the inheriting assessment, and the check that prevents it.
Using an SRM as evidence
A Shared Responsibility Matrix shows which party is expected to operate a requirement. It does not prove that the provider's controls work. Inheritance is granted from the provider's validated assessment results, so an SRM with no matching assessment behind it gives the External Assessor nothing to validate. Before you submit, confirm that the provider's assessment is active and that the SRM rows map to requirements it actually covers.
Claiming full inheritance for shared controls
Full inheritance applies only when a requirement is entirely outsourced to the provider. Many requirements, such as access reviews or incident response, split work between the provider's platform and your own administration. Claiming full inheritance for these is a common reason the assessor rejects the request. Mark each shared requirement as partial and document which side performs each part.
Missing the 30-day request window
External inheritance requests must be submitted no more than 30 days before fieldwork starts and before the 90-day fieldwork window ends. A request filed earlier, or too late, falls outside the workflow the assessor relies on. Build the request into your assessment plan with the fieldwork start date, and confirm the provider's approval turnaround in writing before the window opens.
Relying on a lapsing provider assessment
An inherited score comes from an active source assessment. If the provider's e1, i1 or r2 certification lapses at recertification, or the scores come from an older CSF version your assessment no longer uses, the inheritance has no valid basis. Track the provider's certification end date and any interim assessment due dates, and plan a bridge or fallback for the period when the source is not current.
Failing to document weight rationale
Partial inheritance assigns a weight percentage to each requirement, and the assessor must validate the reasoning behind it. A weight entered without a written rationale, or one that does not match how responsibilities are split, leaves the assessor unable to accept it. For each weighted requirement, record who operates which part of the control and the evidence each party produces.
Who owns the inheritance decision and who validates it
The organization being assessed decides how each requirement is split and owns that decision. For every requirement it wants to inherit, it must document which part a provider covers, which part it keeps, and the weight assigned to each side. Where a requirement is entirely outsourced, the entity can claim full inheritance. Where responsibility is shared, it claims partial inheritance with a percentage per requirement and a written rationale. Your team should own this split from the start, because the assessor will ask the entity, not the provider, to explain why each weight is right.
External requests then pass through the provider. Under the Handbook's approval workflow in MyCSF, the provider approves or rejects the inheritance request, and that request must carry a valid business justification and be submitted within the timing limits in the Handbook. The provider does not decide the weights for you. Confirm with each provider whether its approval covers the whole requirement or only the portion it stands behind, and whether it will publish or share a Shared Responsibility Matrix you can cite in your rationale.
The External Assessor then validates the rationale against the evidence. Only Authorized HITRUST External Assessor organizations may perform validated assessments submitted for certification, and HITRUST performs central quality assurance before any report is issued. DeployOpen prepares the inheritance mapping, evidence packs and documentation so your team and the assessor can trace each weight to a control. DeployOpen does not issue reports or certificates, and it does not decide whether an inheritance is accepted. Ask your assessor early which weights they expect to challenge, and check the assessor's status on HITRUST's Find an External Assessor page.
Questions buyers ask about HITRUST inheritance
Can we inherit from a SOC 2 report instead of a HITRUST assessment?
Inheritance draws only on validated HITRUST results, so a SOC 2 report cannot be inherited in the way this page describes. A provider's SOC 2 report may support how an External Assessor tests a requirement, but that is a reliance decision with its own rules on report age, scope, independence and mapping. Reliance on SOC 2 is covered on a separate page. Do not assume a SOC 2 report transfers scores into your assessment. Ask your External Assessor early which requirements, if any, a SOC 2 report could support, and get that decision in writing before fieldwork starts. A SOC 2 Type I does not qualify for this purpose, so check the report type first.
Does HITRUST inheritance reduce assessment cost and hours?
Yes, it can reduce the hours your assessor spends, and hours are the main driver of assessment fees. HITRUST's 2025 Trust Report, covering 2024 assessments, found that 69% of r2, 67% of i1 and 60% of e1 validated assessments used external inheritance. External Assessors reported 14% fewer hours on r2 assessments, 23.4% fewer on i1 and 9.1% fewer on e1 assessments that used it. These are averages across assessments, not guarantees for yours. Ask your assessor how inherited requirements change the hours in the written quote. Costs that do not shrink include your own preparation, evidence collection for requirements you still own, and the work of preparing inheritance requests.
Who submits an external inheritance request, and who approves it?
The organization undergoing the assessment submits the request, and the provider decides whether to approve it. External inheritance requests go to the provider through MyCSF's approval workflow. The request must be submitted no more than 30 days before fieldwork and before the 90-day fieldwork window ends, and it needs a valid business justification. Your team usually prepares that justification, identifies which requirements the provider's certification covers and aligns the request with the provider's shared responsibility matrix. Once approved, inherited scores cannot be changed by the inheriting entity. An Authorized External Assessor performs the validated assessment, and HITRUST performs central quality assurance before issuing reports. Check the HITRUST Assessment Handbook for the exact request rules.
Can we inherit into an r2 from an e1 assessment?
Inheritance rules allow reuse from any active e1, i1 or r2 validated assessment, so an e1 is a permitted source. Whether it helps your r2 depends on which requirements the source actually validated. The r2 covers a broader set of requirements, so requirements outside the e1's coverage must be tested directly. Confirm with your External Assessor which requirements an e1 source covers and what remains to be tested. Check that the source assessment is active when you submit the request. Inheritance also works across CSF versions, but the version difference still needs assessor review. Readiness or incomplete assessments can only feed readiness assessments, so an unfinished e1 cannot feed an r2 validated assessment. Get both the provider and your assessor to confirm this in writing.
What does our team need to provide for an inheritance request?
Inheritance asks your team for documentation more than for new testing. In practice, your team needs to provide:
- A written scope listing which requirements you will inherit fully or partially, and which you will test yourself.
- For partial inheritance, a weight percentage per requirement and a documented rationale that splits responsibility between you and the provider. Your assessor validates this rationale.
- Evidence for every requirement where you hold sole responsibility, authority and accountability, since inheritance cannot be used there.
- The provider's current shared responsibility matrix and confirmation that the provider's assessment is active.
The quality of the rationale and the currency of the evidence usually decide whether the assessor accepts the inheritance without rework.
Can we run HITRUST inheritance ourselves without a consultant?
Your team can prepare inheritance requests and documentation in-house. The validated assessment itself, however, must be performed by an Authorized HITRUST External Assessor, and HITRUST performs central quality assurance before issuing reports. A consultant or implementation partner can help with the parts you own, such as mapping, evidence, shared responsibility matrix alignment and weight rationales. DeployOpen prepares systems, controls and evidence for assessments, but it does not issue reports or certifications. To decide between in-house work and outside help, ask who can write defensible weight rationales, who owns each control and who will keep evidence current through the fieldwork window. Fixed-scope engagements agree scope, deliverables and timelines in writing before work starts, and a quote follows from that scope.
Where is HITRUST inheritance not allowed?
Inheritance is not allowed where your organization has sole responsibility, authority and accountability for a control. Those requirements must be tested and evidenced by you. Full inheritance is allowed only when a requirement is entirely outsourced to the provider. Where responsibility is shared, the work is partial inheritance, with weights and a documented rationale that the assessor validates. Once an external score is inherited, the inheriting entity cannot change it. HITRUST states that organizations can inherit as much as 70% to 85% of requirements from participating cloud service providers. That is a provider-level claim, so confirm the actual share for your architecture with the provider's shared responsibility matrix and your External Assessor before you plan your scope.
How DeployOpen prepares inheritance-ready evidence
DeployOpen's work on inheritance is preparation, not attestation. For a fixed scope agreed in writing, we help your team decide which requirements in your HITRUST assessment could be inherited from a provider's validated assessment and which must stay with your organization. That decision starts with the provider's Shared Responsibility Matrix and your own system boundary, then moves to a requirement-by-requirement review of who designs, operates and evidences each control. Where the inheritance rules bar inheritance outright, such as where your organization holds sole responsibility, authority and accountability, we say so in the scoping output rather than leaving the gap for the External Assessor to find during fieldwork.
For each requirement proposed for partial inheritance, we prepare the rationale the assessor will need to validate, including the split of responsibility, the proposed weight percentage and the evidence that supports your share. We also document your internal systems that the provider's results do not cover, such as configuration baselines, access reviews and change records in your own environment, so the assessor can test them directly. Anything requested from a provider through MyCSF's approval workflow is tracked with its timing, since external requests must be made within the window the Handbook sets. Confirm with your External Assessor which format they want for these packs before work starts.
The handover is a set of written deliverables: a scoping memo listing each requirement's inheritance route and the reason for it, the rationale and evidence packs per requirement, an inventory of internal systems with their documentation, and a list of open items each owned by a named person on your side. None of these documents is a HITRUST report, certificate or assessment result. Your External Assessor decides what it accepts, and only that assessor's validated report and HITRUST's quality assurance produce a valid outcome. DeployOpen does not guarantee that any requirement will be inherited or that any score will be reached. Ask any implementation partner to state the same boundary in the written scope.
