HITRUST inheritance provider for customers: how to become one

How do you become a HITRUST inheritance provider for your customers?

A vendor becomes a HITRUST inheritance provider only after it holds a current, validated HITRUST assessment whose results it has published for inheritance. Once that is in place, the vendor enables external inheritance in MyCSF, accepts the terms, and approves each request that comes from a customer of the in-scope services. The vendor owns its controls and decides what it shares. An implementation partner can help prepare the systems, configuration and evidence that support the assessment, but the partner does not issue anything. Only the External Assessor performing the validated assessment and HITRUST, which performs central quality assurance before issuing reports, can produce the report and certification that customers rely on.

The answer varies with the assessment type and the customer mix. An e1 or i1 certification lasts one year and an r2 lasts two, so the publication window and the recertification plan differ. The vendor should confirm which assessment it holds, which of its services are in scope, and whether its customers are mostly r2 or i1 users, because that determines how much of the inheritance will be requested. Whether an inheritable assessment remains published after expiry is also a planning point. Confirm the current publication rules with the Assessment Handbook before the certificate is due for renewal.

Before enabling inheritance, a vendor should decide how it will handle requests. Set an internal owner for the MyCSF approval workflow, define what counts as a valid business justification, and check that each requester is a customer of the in-scope services. Decide whether to publish a shared responsibility matrix, which may include weight limits, contacts and processing times. Ask your External Assessor and your HITRUST contact to confirm the terms and how these settings apply to your certification type.

What steps make an assessment inheritable in MyCSF?

The sequence turns a validated HITRUST assessment into one that customers can inherit from, and it keeps that status current through each certification cycle. Each step ends with a visible state in MyCSF that the provider can check before moving on.

Confirm the assessment is certified and in scope
Before anything else, the provider's compliance lead confirms that the validated assessment is certified and that its scope covers the services customers will consume. Only a certified assessment can be made inheritable, so the outcome of this step is a clear record of the certification status and the in-scope services named in that assessment. If the scope does not cover a service a customer uses, the provider should resolve that with the assessor before enabling inheritance.
Enable external inheritance in MyCSF
An authorized administrator opens the assessment in MyCSF and turns on external inheritance. The setting makes the assessment available to other organizations that want to inherit from it, subject to the approval controls that follow. The check that this step is complete is that the assessment shows external inheritance as enabled in the MyCSF settings, with the administrator's name and date recorded in the team's own change log.
Accept the inheritance terms
The same administrator reviews and accepts the terms that HITRUST presents for external inheritance. Accepting the terms is a commitment by the organization, so the person who signs off should have authority to bind the company and should understand the obligations for requests and the scope limits. The output is an accepted-terms record in MyCSF, which the provider should also file with its contract and compliance records.
Set up the approval process for each request
The provider decides who reviews incoming external inheritance requests in MyCSF's approval workflow. Each request must come from a customer of the in-scope services and must include a valid business justification, and the reviewer confirms both before approving. The provider should write this review step into its procedures so that every approval has a named reviewer and a recorded reason. The outcome is a documented reviewer role and a repeatable check.
Publish an SRM with limits, contacts and processing times
This step is optional, but it helps customers scope their requests correctly. The provider publishes its own Shared Responsibility Matrix and may add weight limits that describe how much of a requirement a customer can inherit, plus contacts for questions and the processing times the provider commits to for requests. The check is that the published SRM is visible to prospective inheritors and that the contacts and processing times are current. Confirm with the assessor how the SRM should be presented.
Review each request against the 30-day rule
When a customer submits an inheritance request, the provider checks the timing as well as the content. HITRUST's rules require the request to be submitted no more than 30 days before fieldwork, and before the 90-day fieldwork window ends. The reviewer approves or declines in MyCSF, and the approved request appears in the customer's assessment record. The provider should ask customers early so that timing does not block their fieldwork.
Republish after each recertification
An inheritable assessment unpublishes automatically when its certification expires, and a bridge certificate does not keep it inheritable. The provider should track the expiry date and, once the recertified assessment is issued, enable inheritance again and republish the SRM if it changed. The check is that MyCSF shows the new certified assessment as inheritable before customers submit requests against it. Plan this step ahead of the expiry date so that no customer is left without a source assessment.

How should a provider approve external inheritance requests?

A provider approves external inheritance requests inside MyCSF, and each request must clear three tests before it is accepted: timing, justification and customer status. The request has to be submitted no more than 30 days before the inheriting entity's fieldwork starts, and it must arrive before that 90-day fieldwork window ends. A request that arrives late, or that carries no valid business justification, gives the provider no clean basis to approve it. The reader should map the approval workflow to a named owner, typically someone in compliance or the customer success function who can answer quickly, because a slow decision can push an assessment past its window.

Before approving, the provider should confirm that the requester is a customer and that the services named in the request are in scope for its certified assessment. The provider's terms require it to confirm that each request comes from a customer of the in-scope services, so the check is contractual as well as operational. Record the requester, the customer account, the assessment being inherited from, the requested scope, the justification, the decision, the approver and the date. Keep that log with the contract file, since an External Assessor may ask how a given inheritance was authorized. Confirm the exact fields and retention rules in MyCSF and in your own policy before you build the process.

The approval is an access decision, not a validation of controls. The inheriting entity must use the provider's HITRUST Shared Responsibility Matrix, or HITRUST's baseline SRM template where no provider-specific matrix exists, to see which requirements are inheritable. That SRM tells the assessor where to look, but it cannot be used as scoring evidence. Approving a request therefore does not mean the provider's controls were tested for the customer, and providers should say so plainly in their request responses to avoid customers treating an approval as a guarantee.

What should your published SRM cover?

A provider's Shared Responsibility Matrix is the document inheriting entities read first to see which requirements they can inherit and where their own responsibilities begin. Each card below covers one part of that matrix, and the set is what a customer's assessor will check against the provider's certified scope. Confirm the specifics with your External Assessor and the current HITRUST documentation before you publish.

Which requirements are inheritable

The SRM marks each requirement statement as inheritable from your assessment or as the customer's responsibility. Inheriting entities use your SRM where one exists, or HITRUST's baseline SRM template where it does not, to decide what they can pull from your results. Mark only what your validated assessment actually covers, and keep the marking consistent with the scope and version of the assessment you publish. Ask your assessor to review the inheritable flags before publication.

The SRM is not scoring evidence

An SRM tells the customer where responsibility sits, but it does not prove that a control works. Inheriting entities still need the validated assessment results behind the inheritance, and the matrix cannot stand in for them during scoring. State this clearly in the SRM introduction so customers do not treat the matrix as a substitute for your certification report. Check that every inheritable statement points back to a validated result.

Responsibility boundary with the customer

The most useful part of the SRM is the boundary it draws between your controls and the customer's. Describe what your platform configures, operates and monitors, and what the customer must set up in its own tenant, identity provider, data classification or user access. Vague wording here leads to disputed gaps during the customer's assessment. Walk through a short illustrative example, such as who manages encryption keys, with your assessor before publishing.

Weight limits and scope conditions

The SRM can set limits on the weight an inheriting entity may take from your assessment, so the customer knows how much of its scoring your results can carry. Limits and conditions apply to each request, and an inheriting entity cannot assume that every requirement transfers in full. Publish the limits your assessor has agreed to, and confirm the current rules in the Handbook, since weight rules are part of the assessment method.

Contacts and processing times

An SRM can name the team that handles inheritance questions and state how long your approvals take. Requests must arrive through MyCSF's approval workflow within the timing window set by the Handbook, so a customer that waits too long may lose the chance to inherit within its fieldwork. Publish one monitored contact and a realistic processing commitment, and confirm the approval timing against the current rules before you state any figure to customers.

How widely do customers use inheritance?

In 2024, most validated HITRUST assessments used external inheritance. HITRUST's 2025 Trust Report states that 69% of r2, 67% of i1 and 60% of e1 validated assessments used external inheritance that year. For a provider, these figures mean that a customer's assessor is likely to ask early whether your certification can be inherited, so the SRM, the enablement settings and the republishing schedule should be ready before the first request arrives. The figures describe the market as HITRUST measured it, not a guarantee that any specific customer will request inheritance from you.

The same report says External Assessors recorded fewer hours on assessments that used external inheritance: HITRUST reports 14% fewer hours on r2, 23.4% fewer on i1 and 9.1% fewer on e1 assessments. These are HITRUST-reported averages across assessments, not a promise of savings for your customers. The reduction depends on how much of the customer's in-scope environment your published SRM covers, whether the requests fall within the 30-day window before fieldwork, and how complete the evidence the customer keeps for its own requirements is. Ask your customers to confirm their scope before they count on any reduction.

Treat these numbers as a planning input for your own enablement work. Confirm with your customers which assessment type they are pursuing, since the share of inheritance differs across e1, i1 and r2. Then check the current figures against the HITRUST 2025 Trust Report before quoting them in customer materials, and keep the reference to the 2024 data year.

Who does what when you become a provider?

Your organization owns the controls that customers inherit. No partner or assessor takes that ownership over, and every inheritance decision is made by your team in MyCSF. You enable external inheritance, review each request against the rules, and keep your published matrix accurate for as long as the certification stays valid. Under the Assessment Handbook, these responsibilities are yours alone.

Enable external inheritance: Turn on external inheritance in MyCSF and accept the terms. This step is what makes your assessment available to other entities.
Approve requests: Through the approval workflow, confirm that each requester is a customer of the in-scope services and that the business justification is valid.
Publish your SRM: Decide what your Shared Responsibility Matrix says about weight limits, contacts and processing times, so customers know what to expect before they submit a request.
Republish after recertification: An inheritable assessment unpublishes automatically when its certification expires, and a bridge certificate does not extend inheritability. Plan renewal dates so you can republish promptly.

Before you promise customers any turnaround, check your MyCSF settings and renewal calendar against the provider inheritance sections of the HITRUST Assessment Handbook.

Frequently asked questions

Does a vendor need HITRUST certification before customers can inherit from it?

In practice, yes. Inheritance draws on a validated assessment that HITRUST has certified, and the Handbook ties inheritability to certification status: an inheritable assessment unpublishes automatically when its certification expires. A vendor still in preparation has no certified assessment to publish, so customers have nothing to request against. Plan the certification first, then enable external inheritance and publish your SRM. Confirm the eligibility rules for your assessment type in the HITRUST Assessment Handbook before you promise customers anything, because the sections on inheritance govern what you can publish and when.

How much effort does the external inheritance approval process take?

Each request takes modest effort, but total effort grows with request volume and with how complete your records are. The main drivers are the number of customers requesting inheritance, how current your SRM and contact details are, and whether each request includes a clear business justification. Requests must be submitted no more than 30 days before the customer's fieldwork and before its 90-day fieldwork window ends, so late or early submissions create rework. You must also confirm that each requester is a customer of the in-scope services. Build a documented intake step, assign approvers in MyCSF, and measure the time your first ten or so requests take before you estimate a steady-state load.

Can a customer use inheritance without a shared responsibility matrix?

No. An inheriting entity must use the provider's HITRUST Shared Responsibility Matrix where one exists, or HITRUST's baseline SRM template where it does not. Without one of these, the customer cannot see which requirements are inheritable from your assessment. The SRM also has a limit: it cannot serve as scoring evidence, so publishing one does not replace your validated scores. Your provider-specific SRM can set weight limits, contacts and processing times, which tells customers what they can expect from you. Draft it from your actual assessment results, and review it whenever your scope or certification changes so customers do not inherit against outdated statements.

What happens to inheritance when the HITRUST certificate expires?

The assessment unpublishes automatically at expiry, so it can no longer be inherited from until you republish it. A bridge certificate does not extend inheritability, so a bridge does not keep customer requests flowing. Certification terms set the calendar: e1 and i1 certifications last one year, r2 certifications last two years, and an r2 interim assessment is due in the 90 days before the first anniversary. Put these dates in your compliance calendar and tie republishing to the recertification date. Republish promptly after the new certificate issues, and tell customers who have requests in progress how the gap affects their fieldwork windows.

Can a SaaS vendor set up HITRUST inheritance without outside help?

A vendor can handle the administrative steps itself, including enabling external inheritance in MyCSF, accepting the terms, running the approval workflow and publishing an SRM. The assessment itself is different: validated assessments must be performed by an Authorized HITRUST External Assessor, and HITRUST performs central quality assurance before issuing reports. Many vendors bring in outside help for readiness, SRM drafting and evidence preparation. An implementation partner such as DeployOpen can prepare the platform, controls, documentation and evidence for the assessment in your own environment, but it does not issue reports or certifications. Ask any consultant to show how they keep the SRM aligned with the assessed scope.

Who pays for the External Assessor when a vendor becomes an inheritance provider?

The organization being assessed contracts with and pays the External Assessor for its own validated assessment. Becoming an inheritance provider does not change that arrangement, and each inheriting customer still pays its own assessor for the parts it tests. Assessor fees depend on scope, so ask for a written quote that separates fieldwork, quality review and any MyCSF subscription. The payoff is effort: HITRUST's 2025 Trust Report says 69% of r2, 67% of i1 and 60% of e1 validated assessments in 2024 used external inheritance, and assessors reported 14% fewer hours on r2, 23.4% fewer on i1 and 9.1% fewer on e1 assessments that used it. Those figures are HITRUST's, so check them against your own assessor's estimate.

What usually stalls a provider's inheritance program?

Most inheritance programs slow down for operational reasons rather than assessment failures. The four points below are the places where requests stall, certifications silently drop out of inheritability, or customers receive an SRM they cannot rely on, and each has a check that a provider can put in place before a customer asks.

Requests submitted outside the window

External inheritance requests must be submitted no more than 30 days before fieldwork and before the 90-day fieldwork window ends, and each needs a valid business justification. A request that arrives late, or with a thin justification, can push the customer's assessor into direct testing. Provider teams should confirm, with each customer, the expected fieldwork dates and agree on a named contact who watches the MyCSF approval queue so requests are reviewed inside the window.

Missed republication after recertification

An inheritable assessment unpublishes automatically when its certification expires, and a bridge certificate does not keep it inheritable. If the provider recertifies but forgets to republish, customers lose inheritance mid-assessment without any warning from their own tooling. Add republication to the recertification project plan, assign an owner, and confirm in MyCSF that the assessment is inheritable again before the old certificate's end date passes.

An SRM that does not match the assessed scope

An inheriting entity uses the provider's SRM to see which requirements it can inherit, so an SRM that describes systems, locations or services outside the certified scope invites disputes at fieldwork. Common causes are an SRM written for an earlier scope, a product line added after the assessment, or responsibilities written in general terms. Before each publication, reconcile the SRM line by line against the scope statement and the active assessment, and remember that the SRM is a map, not scoring evidence.

Unclear approval ownership

Inheritance requests need a decision on whether the requester is a customer of the in-scope services and whether the justification is valid. When no one owns that decision, requests sit in the queue, and approvals are given inconsistently across customers. Assign a single accountable approver and a backup, write down the criteria for confirming customer status and justification, and keep a record of each decision so that the provider can show how it handled every request during an assessment.

How DeployOpen prepares a vendor to become an inheritance provider

DeployOpen plans and builds the systems, controls and evidence a platform vendor needs before it enables external inheritance for customers. The vendor owns its HITRUST assessment and its decisions, while an Authorized HITRUST External Assessor and HITRUST handle the validated work and issue the report. Engagements are fixed-scope, with the scope agreed in writing before work starts.

How we scope

We agree in writing which in-scope services, hosting environments and HITRUST assessment type the inheritance program covers.
We map which requirement areas your platform can offer for inheritance and which must stay with each customer.
We define the owners, approval steps and business justification checks your team will apply to customer requests.

How we build

We configure the self-hosted platform and its logging, access and change records so the evidence behind each inheritable requirement is retrievable.
We draft your Shared Responsibility Matrix, with customer responsibilities, weight limits, contacts and processing times stated plainly for your team to approve.
We test the evidence trail and the external inheritance workflow in MyCSF before your first customer request arrives.

How we hand over

We document the request intake, approval and republishing procedures so your staff can run them without us.
We deliver the SRM, evidence index and runbooks in editable formats that your compliance team owns.
We set a recertification calendar that flags when an inheritable assessment expires, so it is republished promptly and does not lapse.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the initial engagement.
A retainer can cover updates to the SRM when your services or the HITRUST CSF version change, subject to the written scope.
Your independent assessor, not DeployOpen, decides what the validated assessment accepts as evidence and issues the report.

Becoming a HITRUST inheritance provider for your customers