HITRUST carve-outs vs inheritance for service providers

Carve-out or inheritance for a HITRUST service provider: which to choose

When a customer or contract requires HITRUST and a cloud or SaaS provider sits inside the assessment boundary, the first decision is how that provider gets covered. An e1 or i1 can carve out a third party if its responsibilities are documented and it is removed from scoring entirely, while an r2 allows no carve-outs at all, so the provider's requirements must be covered another way. Whichever route you take, the choice depends on three things: the assessment level you are pursuing, how much of each requirement the provider actually owns, and whether the provider already holds a HITRUST certification or a relevant audit report.

HITRUST recognizes four ways to cover an in-scope third party: inheriting HITRUST results from a validated assessment, relying on a third-party audit report, relying on your own internal assessors, or testing the third party directly. If none of these covers a requirement for that party, the requirement is scored not compliant for that party. This is the point most teams miss. A carve-out removes the provider from scoring, but only where your documentation shows exactly which responsibilities sit with the provider. Marking a requirement N/A because a vendor performs it is not a valid rationale outside a documented e1 or i1 carve-out, so check each requirement against one of the four routes before you decide.

Your organization owns its controls. An implementation partner such as DeployOpen can help prepare systems, documentation and evidence for the chosen route, but only an authorized HITRUST External Assessor performs the validated assessment and issues the result. Before you commit, ask your provider for its current HITRUST status and the scope of its certification, confirm with your assessor which routes it will accept for your assessment level, and check the HITRUST assessment handbook sections on carve-outs and third-party coverage before you finalize your scoping.

What a carve-out requires in an e1 or i1

An e1 or i1 can leave a third party out of scoring, but only when the Handbook conditions are met on paper and in practice. The cards below cover what must be documented, how N/A rationales work and where the organization's own duties remain.

Documented responsibilities come first

A carve-out starts with a written record of what the third party does and what the organization still does. The assessor needs to see which controls the provider operates, which systems and data it touches and where the boundary between the two parties sits. Without that document, the carve-out has no basis and the assessor cannot test it. Check that the description names specific services and that it matches the provider's contract and actual architecture.

Removal from scoring entirely

A carved-out third party is taken out of scoring altogether, not scored at a lower level or treated as partially compliant. Its controls do not count toward the organization's maturity results. This is why the choice matters: a carve-out removes the provider's contribution in both directions. Confirm with the assessor that the provider appears as excluded in the scope documentation and that no score quietly includes it.

N/A for fully owned requirements

Requirements that the third party fully owns are marked N/A, and each N/A needs a rationale. The rationale must cover every system, facility and third party in scope, not only the provider named in the carve-out. A partner's ownership is accepted only when the carve-out is documented, so the N/A and the carve-out must agree. Review each N/A line against the carve-out record before submission.

Third party performing is not enough

Saying that a vendor performs a requirement is not a valid N/A reason outside a documented carve-out. Inside an e1 or i1 without a carve-out, the requirement stays in scope and must be covered by inheritance, reliance on a report or direct testing. Teams often write vendor-performs rationales for controls they never formally carved out, which an assessor will reject. Check each rationale for this wording.

Activity not occurring is never valid

An N/A cannot be justified by the fact that an activity does not happen in the environment. If a process applies to the organization and is simply not performed, the requirement is not applicable only in the narrow sense the Handbook defines, and that is not a reason to skip it. For example, a team that runs no wireless networks still needs a clear rationale tied to the scope, not an assumption that the control does not apply. Ask the assessor to confirm which activities are truly out of scope.

Organization keeps its own duties

A carve-out removes the provider from scoring but does not remove the organization's responsibility for requirements it still owns. Those controls remain in scope, need evidence and are tested like any other. Carving out a cloud or service provider is a scoping decision, not a transfer of accountability to the vendor. Confirm which requirements stay with the organization before the carve-out is finalized.

Why the r2 allows no carve-outs for service providers

The r2 does not let you carve out service provider requirements, which is the central difference between it and the e1 and i1. In an e1 or i1, a third party can be removed from scoring entirely if its responsibilities are documented and the requirements it fully owns are marked N/A with a rationale. The r2 offers no such route. Every in-scope third party stays in the scoring, so the controls a cloud host, payroll processor or managed security provider performs for you must still be evidenced and scored in your assessment.

The practical consequence is that each third-party-performed requirement needs one of four coverage routes: inheriting validated HITRUST results from the provider, relying on an eligible third-party audit report, relying on your own internal assessors, or having the External Assessor test the provider directly. If none applies to a requirement, that requirement scores as not compliant for that party. Before you start the r2, list every provider in scope and, for each one, record which route covers which requirements. Confirm early with your External Assessor which reports they will accept, because a route that works for an e1 may not carry over unchanged.

The r2 is the deeper assessment meant to test the full scope, including outsourced controls, so the question to answer early is which of your providers you can cover with reliance rather than fieldwork. Two other r2 features do not change this rule. You can tailor the r2 to include privacy, and you do not have to use the newest CSF version when you create it. Both affect which requirements are in play, but a provider's controls still need one of the four coverage routes whatever version or tailoring you choose.

When inheritance, reliance on reports or direct testing is the better route

A carve-out may fit an e1 or i1 where a provider owns only a small set of requirements outright and your organization has no other reason to score it. The provider is removed from scoring entirely, so its responsibilities must be documented clearly enough that the assessor can see nothing falls between the two parties. Requirements the provider fully owns are marked N/A, and each N/A needs a rationale. This route does not apply to an r2, which allows no carve-outs of service provider requirements.

Documented responsibilities: Write down exactly which requirements the provider owns and confirm the provider accepts them in writing.
Full ownership test: Carve-out is for requirements the provider fully owns, not partly covers.
N/A rationale: Each N/A needs a reason covering every system, facility and third party in scope.
No gaps: Anything you cannot show the provider owns stays in your scope.
Narrow fit: Large or shared responsibilities usually belong in inheritance or testing instead.

Check whether a carve-out still fits your assessment type and whether your customers will accept it for the scope they rely on.

How inheritance differs from a carve-out

A carve-out removes a third party from scoring, while inheritance keeps that party in scope and reuses its validated maturity scores. The cards below separate the two routes, the rules that govern each, and the checks an assessor will make before accepting either.

What inheritance reuses

Inheritance takes maturity scores from another active HITRUST e1, i1 or r2 validated assessment, either your own or a provider's. The source assessment can be on a different CSF version than yours, so the score transfers across versions. Confirm that the source assessment is still active on the date you submit the request, because an expired or superseded assessment cannot be used.

Provider stays in scope

A carve-out removes the provider from scoring entirely, while inheritance keeps it in scope and counts its results toward your requirements. The provider remains part of your assessed environment, so every system and facility it touches must still be described. Ask your assessor which provider systems appear in scope and which are covered only by inherited results.

Full inheritance for outsourced requirements

Full inheritance applies only when a requirement is entirely outsourced to the provider. If you still perform any part of the requirement yourself, full inheritance is not available for it. Check each requirement against your own responsibilities before you claim it as fully inherited.

Partial inheritance under shared responsibility

Where you and the provider split a requirement, partial inheritance applies, with a weight percentage assigned to each requirement. Each weight needs a documented rationale that your assessor validates. Weights must match the actual division of work, so a generous weight without evidence will not hold up at validation.

Readiness work has narrower rules

Readiness or incomplete assessments can only be inherited into readiness work, not into a validated e1, i1 or r2. Do not plan a certification around a provider's readiness report, even if its scores look strong. Ask the provider for its latest validated assessment and its date before you build your plan.

Requests need provider cooperation

Inheritance depends on the provider approving and supplying its assessment results, so the request is only as fast as the provider's process. Confirm in writing how it handles external inheritance requests, which documents it releases and whether it requires a shared responsibility matrix. Carve-outs need none of this, which is why they are often chosen for speed rather than accuracy.

What each route costs and who gets paid

This table compares the four ways to cover a third party in a HITRUST assessment: carve-out, inheritance, report reliance and direct testing. No supplied figures exist for these costs, so the drivers are scope and evidence, not a quoted price. Ask each candidate for a written list of affected requirements and the assessor's validation effort before comparing totals.

Route	Who is paid and for what	One-time or recurring, and what drives it
Carve-out (e1 or i1 only)	External Assessor validates the documented responsibilities and N/A rationales. Internal staff document the boundary. An implementation partner may prepare the documentation.	Mostly one-time per assessment. Cost rises with the number of carved-out third parties and the number of requirements marked N/A that need rationale.
Inheritance from a provider's HITRUST result	Provider supplies its validated assessment and request responses, often at no direct charge to you (confirm with the provider). Internal staff review weights, and the External Assessor validates partial inheritance rationales.	Request handling recurs with each assessment cycle. Cost rises when the provider's assessment is stale, the SRM is unclear, or many requirements need partial weights.
Reliance on a third-party audit report	The External Assessor reviews the report for age, scope and mapping. Internal staff gap-check what the report does not cover. The provider is paid by its own auditor, not by you.	Recurs with each report cycle. Cost rises with the number of domains the report does not map to and any bridge testing needed for report age.
Direct testing of the third party	External Assessor tests the provider's controls directly. The provider or its staff supply evidence. Your organization may pay for access, testing time and evidence preparation.	Highest effort and the most likely to recur. Cost rises with the number of requirements, sampling depth and the provider's willingness to grant access.
Internal assessor coverage	Your own internal assessors produce scores that can be inherited into your assessment. Staff time and training are the main costs.	Largely internal labor that recurs. Cost rises with the number of in-house staff qualified to assess and the breadth of scope.
Quote request: affected requirements	Ask each route's provider and your assessor for a written list of the requirements each route covers, marked full, partial, carve-out or N/A.	Ask for this list before signing. It turns a vague price into a scope you can compare across options.
Quote request: assessor validation effort	Ask the External Assessor how much validation effort each route needs, including review of N/A rationales, weights and report mapping.	Validation effort is the main driver of assessor fees. Ask for hours or days in writing, and confirm whether validation is priced separately from fieldwork.

How to work through provider decisions before fieldwork

This sequence turns a list of outside providers into a documented, assessor-confirmed decision for each in-scope requirement, so the validated assessment starts with settled scope and evidence rather than open questions.

List every in-scope third party
Start with the system and facility boundary for the assessment, then list every third party that hosts, processes, transmits or administers in-scope data or systems. Include cloud platforms, managed service providers, SaaS tools in the data path and any subcontractors your vendors rely on. Ask each vendor whether it holds a current HITRUST result, a SOC 2 Type II report or another audit report. The output is a third-party register tied to the assessment scope, and you know this step is done when every in-scope system maps to a named provider or to your own organization.
Classify what each provider owns
For each provider, record which requirements it performs entirely, which it performs partly and which remain with your organization. Work from the provider's contract, its responsibility documentation and its own assessment scope rather than from marketing material. Flag any requirement where the split is unclear, since those will need a documented position later. The output is an ownership worksheet per provider, and the step is complete when every in-scope requirement is assigned to you, to a provider in full, or to a provider in part.
Choose the route for each requirement
Decide, per provider and per requirement, whether the treatment will be a carve-out (e1 or i1 only), inheritance, reliance on a third-party audit report, reliance on your internal assessors, or direct testing. Carve-outs are not available in an r2, so the r2 route for a provider is always one of the other options. Where a provider fully owns a requirement, full inheritance is the question; where responsibility is shared, partial inheritance is the question. The output is a route decision per requirement, and you know it is done when each cell in the worksheet has one route and no requirement is left without a route.
Collect the provider's HITRUST result, report or SRM
Request the evidence each chosen route depends on: the provider's validated assessment results and certification letter, the audit report and its scope and period, or the provider's shared responsibility matrix. Confirm the assessment is active, the scope covers the services you use, and the CSF version is recorded. Check that the materials are current and that any incomplete or readiness assessment is not being used for a validated result. The output is an evidence file per provider, and you know this step is done when each provider has a dated, in-scope source for every route it supports.
Document the carve-out or inheritance rationale
Write a rationale for each provider decision. For a carve-out, record the documented responsibilities and mark fully owned requirements as N/A with a rationale that covers every system, facility and third party in scope. For inheritance, record the source assessment, the requirements inherited, and the weight for partial inheritance with the reason the split is correct. Avoid rationales that rely only on a provider performing the activity or on an activity not occurring, since those are not valid reasons for N/A. The output is a signed-off rationale log, and the step is complete when every decision points to a specific source and a specific responsibility split.
Test the decisions with the external assessor
Take the rationale log, the route worksheet and the evidence file to your External Assessor before fieldwork begins. Ask the assessor to confirm eligibility of each source assessment, the weights for partial inheritance, the carve-out treatment in e1 or i1, and any requirement where the assessor expects direct testing. Record the assessor's position in writing and resolve any disagreement before the work starts. The output is an agreed decision record, and you know this step is done when the assessor has confirmed each provider route in writing.
Hand agreed decisions into fieldwork
Lock the agreed route decisions into the assessment scope and share the rationale and evidence with the team that will collect fieldwork evidence for your own controls. Assign owners for any requirement still tested directly and set up a process to track changes if a provider's scope or certification status changes. The validated assessment fieldwork window is at most 90 days for e1, i1 and r2, so settled provider decisions leave more of that window for your own testing. The output is a locked scope and owner list, and the step is complete when fieldwork starts with no open provider questions.

Mistakes that turn a carve-out into a failed assessment

Most failed provider treatments in HITRUST work come from a handful of predictable errors, not from the assessor finding something new. The cards below cover where teams misapply carve-outs, N/A decisions and inheritance, and what to check before the assessor's fieldwork begins.

Carving out a provider in an r2

The r2 does not allow service provider requirements to be carved out, so a team that carves out a cloud host or vendor in an r2 is working from the wrong rules. The provider's requirements stay in scope and must be covered by inheritance, a third-party audit, internal assessor work or direct testing. Before scoping, confirm the assessment type and check that no provider has been removed from scoring on the assumption that carve-outs apply.

Marking requirements N/A for provider work

A requirement is not N/A because a provider performs it. Under the rules, a third party performing a requirement is not a valid N/A reason except under a documented e1 or i1 carve-out, and an activity simply not occurring is never valid either. Review each N/A rationale and confirm it covers every system, facility and third party in scope.

Relying on a SOC 2 Type I report

A SOC 2 Type I describes controls at a point in time and does not test their operation over a period, so it does not qualify as a basis for reliance in a HITRUST assessment. Teams sometimes present it because it is the report the provider has on hand. Ask the provider for a Type II report covering a current period, and check its scope against the services your environment uses.

Inheriting an incomplete or readiness assessment

Only active, validated e1, i1 or r2 assessments can be inherited into a validated assessment. Readiness or incomplete assessments can be inherited only into readiness work, so a provider's readiness report does not cover your requirements in a certification. Confirm the source assessment's status and type in writing before you build the inheritance request around it.

Mismatching CSF version or scope

Inheritance reuses maturity scores across CSF versions, but the provider's assessment still has to match the systems, facilities and services your environment actually uses. A provider certified for one product line may not cover the platform you run on it. Compare the provider's scope statement with your system boundary and document any gap that will need partial inheritance or direct testing.

Leaving gaps at provider recertification

A provider's certification has a set validity period, and its recertification can leave a window in which inherited requirements have no current source. An e1 or i1 lasts one year and an r2 lasts two years, with an r2 interim assessment due in the 90 days before the first anniversary. Track the provider's dates, request its renewal timeline in advance, and plan a fallback such as direct testing or a report-based reliance for the gap period.

Common questions about carve-outs and inheritance

Can a cloud provider be carved out of an e1 assessment?

Yes, an e1 can carve out a third party, but only under specific conditions. The provider's responsibilities must be documented, the provider is removed from scoring entirely, and any requirement the provider fully owns is marked not applicable with a rationale. The same carve-out option exists in an i1. Carving out does not mean the requirements disappear. Your organization still has to show that its own side of each shared control works, and the assessor will check that the documentation matches what the provider actually does. Ask your assessor early whether the carve-out boundary fits your architecture, because a poorly drawn boundary often leads to rework late in the engagement.

Why can an r2 assessment not carve out service providers?

An r2 does not allow service provider requirements to be carved out, so every in-scope third party must be covered through one of HITRUST's recognized routes. Those routes are inheriting HITRUST results, relying on third-party audits, relying on the entity's internal assessors, or testing the third party directly. If none applies to a requirement, that requirement is scored not compliant for that party. In practice, this means an r2 team has to decide early how each provider will be covered, since the choice affects evidence collection, scope and timing. Confirm the current rules in the HITRUST Assessment Handbook before you plan, because the handbook is the controlling document.

Can we inherit results from our own earlier HITRUST assessment?

Yes. HITRUST allows inheritance from an entity's own active e1, i1 or r2 validated assessment, which is called internal inheritance, as well as from a provider's assessment. The source assessment must still be active, and inheritance can cross CSF versions. Readiness or incomplete assessments can only be inherited into readiness work, not into a validated assessment. Full inheritance applies only when a requirement is entirely handled by the source, while shared responsibility calls for partial inheritance with weights and a documented rationale that the assessor validates. Internal inheritance works best when the earlier scope closely matches the new one, so compare system boundaries before you request it.

What does our organization have to provide for inheritance or a carve-out?

Your organization has to supply the evidence that makes the boundary decision defensible. For a carve-out, that means written documentation of the third party's responsibilities, a clear list of the in-scope requirements affected, and rationales for each not applicable decision. For inheritance, you need the source assessment's identifiers and validation details, the requirements you intend to inherit, and, for shared responsibility, the weights and rationale for each partial inheritance. You also need your own controls for everything the provider does not cover, with evidence that they operate. The assessor will validate all of it, so organize the package around what they will test rather than around what is easiest to collect.

Can a consultant or implementation partner prepare the carve-out documentation for us?

A partner can help prepare the documentation, but the organization owns the controls and the decisions. DeployOpen, for example, prepares systems, controls and evidence for compliance assessments, including the material that supports scoping and inheritance choices. It does not issue audit reports, attestations or certifications. Only an authorized HITRUST External Assessor can perform a validated assessment submitted for certification, and HITRUST performs central quality assurance before issuing reports. The partner's work is useful when it produces accurate boundary diagrams, consistent rationales and evidence the assessor can test. It is not a substitute for your own sign-off on what your organization is responsible for.

Who issues the HITRUST result when inheritance or a carve-out is used?

An authorized HITRUST External Assessor performs the validated assessment, and HITRUST issues the resulting report and certification after its central quality assurance. Your organization, a consultant or an implementation partner cannot issue the result. Inheritance and carve-outs change which requirements the assessor tests directly and how scores are assembled, but they do not change who decides the outcome. Ask the assessor, before fieldwork begins, how they will validate each inherited score and each carve-out rationale, so that surprises do not appear at the reporting stage.

How does a carve-out affect the cost and timeline of an assessment?

A carve-out usually reduces the testing scope for the assessor, but it adds documentation and boundary work for your team. The main cost drivers are the number of third parties in scope, how many requirements each one touches, and how much of your own evidence the assessor still needs to see for shared controls. Recurring costs depend on how often the provider's documentation or certification changes. To compare options, ask each assessor for a quote that separates carve-out, inheritance and direct testing work, and ask what each route requires from your team. Timelines depend on how quickly the provider's documents arrive and on the assessor's fieldwork window, which the handbook caps at 90 days for e1, i1 and r2.

When is a carve-out a better route than inheritance or direct testing?

A carve-out fits best when a third party fully owns a set of requirements, the assessment is an e1 or i1, and the responsibility boundary is clean and documented. Inheritance is usually better when the provider holds a current HITRUST result that covers the requirements, or when your organization has its own recent validated assessment. Direct testing or reliance on a third-party audit fits when the provider has no usable HITRUST result and the requirements are shared. Illustrative example: a SaaS company whose hosting provider holds an active validated assessment might inherit hosting controls, carve out a payroll processor it fully outsources, and test its own application controls directly. Confirm each choice against the handbook and your assessor's view before committing.

How DeployOpen prepares provider documentation and evidence

DeployOpen helps regulated organizations decide which third parties to carve out, which to cover through inheritance or reliance on reports, and which to test directly, then prepares the documentation and evidence that supports that choice. Your organization owns its controls and its decisions, and only an authorized HITRUST External Assessor issues the validated report.

How we scope

We map each in-scope third party to the route it will take: carve-out, inheritance, report reliance or direct testing.
We confirm which HITRUST assessment type applies, since carve-outs are available only in e1 and i1 assessments, not r2.
Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we build

We document each third party's responsibilities and draft the rationale for any N/A requirement or carve-out.
We prepare shared responsibility records and weight partial inheritance so the assessor can validate each split.
We build the evidence trail for requirements your own systems must still meet, including those a provider cannot cover.

How we hand over

You receive the carve-out and inheritance documentation, rationales and evidence index in a form your assessor can review.
We walk your team through which requests your provider must answer and which gaps remain open for you to close.
Your assessor decides what is accepted. DeployOpen does not issue reports, attestations or certifications.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, so provider documentation stays current.
We can revisit carve-out and inheritance decisions when a provider changes its scope, certification or CSF version.
Ask us to confirm which parts of your environment and provider relationships fall inside the written scope before work begins.