What a HITRUST shared responsibility matrix tells you before an assessment
Suppose your customer contract requires a HITRUST certification and your platform runs on a cloud provider. An SRM shows which requirements that provider can cover and which stay with you. It is not scoring evidence: an assessor will not accept the matrix itself as proof that a control operates. Before you plan any inheritance, you need to know which requirements are candidates for transfer, and the matrix is where that starts. The actual split depends on three inputs: the provider's own SRM where one exists, HITRUST's baseline SRM template where it does not, and your system design, since the same provider service can be configured in ways that move responsibility back to you. HITRUST states that organizations can inherit as much as 70% to 85% of requirements from participating cloud service providers, but that range describes the category, not your environment.
Your organization owns its controls. Only an authorized HITRUST External Assessor issues validated results, and HITRUST performs central quality assurance before a report is issued. A DeployOpen engagement, where one is agreed in writing, covers preparing systems, configurations and evidence for that assessor, and mapping which of your own controls align with each SRM line. It does not change who is accountable for the control or who signs the result. Confirm with your assessor, early, which SRM version and provider assessment they will accept, because a matrix that does not match the assessment in scope will stall the request.
Start by pulling the provider's SRM from HITRUST's inheritance program page and marking every line you would depend on. For each marked line, record who operates the control, what the provider's assessment covers, and what evidence you still need to produce yourself, such as your own access reviews, configuration baselines or incident records. Where the matrix is silent or your design differs from the provider's default, treat the requirement as yours until you have documented rationale the assessor can validate. Note that partial inheritance requires weight percentages and a rationale per requirement, so the matrix is a planning input for those decisions, not a substitute for them.
How each SRM entry is used in an inheritance request
A requirement qualifies for full inheritance only when it is entirely outsourced to the provider. The provider performs every part of the control, so the customer has no remaining task for it. In the request, the customer identifies the requirement, the provider's source assessment and the SRM entry that marks the requirement as fully provider-owned. HITRUST's inheritance rules allow full inheritance only on that basis, and the Assessment Handbook sets out the request mechanics. Physical security of a data center is the usual example, because the provider owns the facility, its access controls and its environmental systems.
- Entire ownership: the provider runs every step of the requirement, with no customer action attached to it.
- Request content: the request names the requirement, the provider's validated result and the matching SRM entry.
- Customer-side records: you keep the request record, a copy of the provider's certification status and proof that the services you use are the in-scope services covered by that result.
- Scope match: a workload outside the provider's in-scope services cannot inherit, even if the requirement is fully outsourced in principle.
- Current source result: the provider's underlying result must still be valid on the date you submit the request.
Before you treat an entry as full inheritance, confirm that the SRM marks it as wholly provider-owned, because any entry that needs a customer action is partial by definition.
Most requirements in a cloud or platform environment are shared, meaning both parties perform part of the control. The SRM shows the split, and partial inheritance turns that split into numbers. For each shared requirement, the customer assigns a weight percentage that reflects the provider's share and writes a rationale explaining who does what. The assessor validates both the weights and the rationale. The customer still performs and evidences its own share. An illustrative case: the provider patches the underlying hypervisor, while the customer patches its own guest operating system and applications.
- Weight percentages: the request states how much of the requirement the provider covers, and the remaining share stays with you.
- Documented rationale: a written explanation of the division of tasks, tied to the SRM entry, that the assessor will read and challenge.
- Customer share evidence: change tickets, configuration baselines, logs or review records that show your portion operating across the assessment period.
- Boundary consistency: the division must follow the provider's stated responsibilities and your in-scope services, not your preferred allocation.
- Assessor scrutiny: weights the provider's SRM does not support will be questioned, which can delay the result or reduce the inherited credit.
Before you submit, confirm that every shared entry has both a weight and a rationale, and that you own evidence for the remaining percentage.
A requirement the customer retains receives no inheritance at all. The SRM marks it as the customer's responsibility, so you test and evidence it directly within your own assessment. Governance, policy ownership and the operation of your own information protection program usually remain with you. HITRUST's example for a cloud provider lists the information protection program as not inheritable, since the customer must own its program, governance and policies. Third-party assurance is similar: you review your providers' compliance reports and manage assurance over your own vendors, even when those providers hold their own certifications.
- No inherited credit: the requirement stays out of the inheritance request, so no provider result is applied to it.
- Owned policies and governance: you write, approve and maintain the policies and program the requirement describes.
- Vendor oversight: you review provider reports, track their exceptions and decide how to act on them.
- Direct evidence: approvals, samples, meeting records and review outputs produced by your own teams during the assessment period.
- Named ownership: each retained requirement has an internal owner who can produce evidence on request.
Before fieldwork begins, check that every entry the SRM marks as retained has a named owner and an evidence source inside your own environment.
Why an SRM is not evidence
A Shared Responsibility Matrix settles who answers for which requirement, and nothing more. The cards below set out what it cannot prove, what the Handbook does with it, and what to request instead when you plan an inheritance request.
It states allocation, not operation
An SRM records which party is meant to own each requirement, often with a note on what the provider does and what the customer does. It does not show that any control ran, passed or was tested. Read each row as a claim to verify. Ask the provider for the validated assessment results behind the rows you plan to inherit, and check that the scope of those results matches the services you actually use.
It is not scoring evidence
Under the HITRUST Assessment Handbook, the SRM itself cannot be used as scoring evidence. Inheriting entities use the provider's SRM, or HITRUST's baseline SRM template when no provider SRM exists, to see which requirements are inheritable. Your External Assessor still needs the validated results themselves before any score can move. Plan your evidence list around that distinction from the start.
Results must come through a request
Provider results reach your assessment only through an inheritance request that the provider approves. The SRM tells you which requirements are candidates, but it does not transfer any score by itself. Confirm that the provider has external inheritance enabled, that the request is tied to the in-scope services, and that the timing lines up with your assessment window before you build your narrative around inherited scores.
Your configuration remains yours
Even a fully described provider responsibility does not cover how you configure the provider's services. Access policies, encryption settings, logging choices and network rules in your own tenant stay in your scope. Ask for evidence of your own configuration reviews and change records for these items, and treat any SRM row that mentions customer configuration as an open item until you have that evidence.
Matrices go stale
An SRM describes a provider's services and your architecture at one point in time. A new service, a changed region, a new integration or a provider's version change can move responsibility without anyone updating the matrix. Compare the SRM version and date against the provider's current validated assessment, and re-check the rows at every assessment cycle and after any significant change to your environment.
Ask for operating evidence
Instead of relying on the matrix, request the provider's current validated assessment and its scope statement, then gather your own operating evidence for everything the matrix leaves with you. That means access review records, configuration baselines, change tickets, monitoring outputs and incident records that show each control working over the assessment period. Your External Assessor will test the evidence, not the matrix.
Which domains rarely transfer from a cloud provider
This table compares three assessment domains from HITRUST's Oracle Cloud Infrastructure inheritance example, showing where a cloud provider's results transfer and where the customer must do its own work. Treat the rows as HITRUST's illustration, not a ruling on your provider, and check each domain against your own provider's SRM before you plan scoping.
| Domain | Inheritability from cloud provider | Why it does or does not transfer |
|---|---|---|
| 01 Information Protection Program | Not inheritable | The customer must own its information protection program, governance and policies. A provider cannot set these for your organization. |
| 19 Data Protection & Privacy | Check the SRM | Privacy obligations depend on what data you hold and how you use it. Confirm which parts the provider's SRM marks as partial or customer-owned. |
| Third-Party Assurance | Not inheritable | The customer reviews its own providers' compliance reports and manages assurance over its own vendors, so the cloud provider cannot cover that work. |
| Physical & Environmental Security | Highly inheritable | In HITRUST's illustration, the provider fully manages data center security, biometrics, HVAC and redundant power, which supports full inheritance. |
| Shared responsibility domains generally | Partial | Where the SRM splits the work, the requirement needs weighted partial inheritance and a documented rationale that the External Assessor validates. |
How a shared responsibility matrix moves through an inheritance request
The sequence turns a provider's published SRM into a scored, partially inherited requirement set that the External Assessor can test. Each phase produces a document or record that feeds the next, so the request stays traceable from the first mapping to fieldwork.
Obtain the provider's SRM or baseline template
Start by locating the provider's HITRUST Shared Responsibility Matrix. If the provider has none, use HITRUST's baseline SRM template instead. The matrix shows which requirements the provider can make inheritable and where the customer keeps responsibility. Confirm the matrix version and the in-scope services it covers with the provider. The output is a dated copy of the SRM filed in your assessment workpapers.
Map in-scope requirements to the matrix
Compare each requirement in your assessment scope against the SRM entry for the provider. Mark each one as fully outsourced, shared, or customer-owned, and note which provider services support it. Pay particular attention to domains that rarely transfer, such as information protection program governance and third-party assurance. The output is a requirement-level map that shows every candidate for inheritance and every item you must still evidence yourself.
Agree the inheritance type and weights
For each mapped requirement, decide whether the inheritance is full or partial. Full inheritance applies only when the requirement is entirely outsourced to the provider. Shared requirements call for partial inheritance, with a weight percentage for the portion the provider covers and a written rationale for that split. Agree the figures with the provider and your assessor before submission. The output is a signed-off inheritance worksheet with weights and rationale for each requirement.
Confirm the provider has enabled external inheritance
Before submitting, verify that the provider has enabled external inheritance in MyCSF, accepted the terms, and published its SRM, weight limits, contacts and processing times. Confirm that your organization is a customer of the in-scope services covered by the provider's assessment. Without these checks, the provider's workflow will not accept the request. The output is a written confirmation from the provider covering enablement and customer status.
Submit the request in the provider's workflow
Submit the inheritance request through the provider's inheritance workflow in MyCSF, attaching the requirement map, the agreed weights and the rationale for each partial inheritance. The provider reviews the request, confirms that it comes from a customer of the in-scope services, and approves or returns it. Keep the approval record with the request. The output is an approved request tied to specific requirements and weights.
Keep the rationale ready for fieldwork
The inherited scores do not pass to your assessment automatically. Keep the SRM, the weighted map and the approved request ready for the External Assessor, and collect your own evidence for every customer-owned and shared portion. The SRM itself cannot serve as scoring evidence. The output is an evidence set linked to each inherited and retained requirement.
Have the External Assessor validate the rationale
During validated assessment fieldwork, the External Assessor tests whether the inheritance rationale holds for each partially inherited requirement. The assessor checks that the matrix supports the split, that the provider's validated results apply to the in-scope services, and that your own portion is evidenced. Only an Authorized HITRUST External Assessor performs this validation, and HITRUST performs central quality assurance before reports are issued. The output is the assessor's validated inheritance determination within the assessment report.
Mistakes that delay or weaken an inheritance request
Most stalled inheritance requests trace back to a few avoidable errors in how the matrix is chosen, read and documented. Each card below names one error, why it matters for the request, and a check you can run before the assessor sees it.
Using a baseline SRM when a provider SRM exists
Inheriting entities must use the provider's own HITRUST Shared Responsibility Matrix where one exists, and fall back to HITRUST's baseline SRM template only when it does not. A baseline template can mark a requirement as inheritable where the provider's matrix shows the customer must keep ownership, or the reverse. Before you build the request, confirm with the provider whether it publishes a matrix for the in-scope services and map every line against that version.
Treating an SRM line as proof
An SRM shows who is responsible for a requirement, but it cannot be used as scoring evidence. A provider's matrix saying a control is inheritable does not show that the control operated during the assessment period. For each inherited requirement, pull the provider's validated assessment results and confirm the assessor can see the scored evidence behind that line.
Leaving out weight rationales
Shared responsibility calls for partial inheritance, with a weight percentage per requirement and a documented rationale the assessor validates. Requests that list weights without explaining why the split is correct are returned or challenged. Write one short rationale per requirement that names what the provider manages, what you manage and where the boundary sits, then check that each rationale matches the matrix line it supports.
Requesting from a provider whose scope does not match
Inheritance depends on the provider's certification covering the services you actually use, not just the provider's name or its headline certificate. Check the assessed scope in the provider's report for each service, region and environment you depend on. If a service sits outside that scope, requirements tied to it cannot be inherited, and you will need to test them yourself or carve them out where the assessment type allows.
Ignoring the provider's recertification gaps
A provider's certification has a fixed validity period, and a gap between an expiring assessment and its successor can leave inherited requirements without a current source. Ask the provider for its recertification timeline and any bridge arrangements before your own assessment window opens. Record a plan for the gap, such as incubation of the new provider results or a documented interim position, so the request does not fail at your next reporting point.
Assuming the matrix is final after one review
Providers can revise their SRMs as the CSF changes, and a matrix downloaded months earlier may no longer match the version in use. Before submission, confirm the matrix version, date and the CSF version it references. Re-check every inherited line against the current matrix, and note the version you relied on in your request so the assessor can reproduce your reading.
Who owns the SRM, the evidence and the scoring
The customer is the organization being assessed, and it owns its controls, its retained requirements and its inheritance requests. An SRM tells the customer which requirements a provider may cover, but the customer still decides how each requirement is scoped into its own environment and remains accountable for any part the provider does not own. The customer also submits the inheritance request in MyCSF and must explain how the provider's results apply to its own systems.
- Retained requirements: Requirements the SRM assigns to the customer, such as its information protection program, governance and policies, stay fully in its scope.
- Request and rationale: The customer documents why each inherited requirement applies to its services and why the weight it claims is appropriate.
- Own evidence: Access reviews, change records, configuration baselines and training records for the customer's own environment must exist independently of the provider.
- Contract terms: The customer confirms the provider's in-scope services match the systems it actually uses.
- Ongoing currency: The customer tracks when the provider's assessment is renewed so inherited results do not lapse.
Before submitting, check that every retained requirement has evidence the customer can produce on its own.
The provider publishes the SRM that describes which requirements it covers and where its responsibility stops. Its role in an inheritance request is to confirm that the request comes from a customer of the in-scope services and to approve or manage the inheritance under its own terms. The provider's validated results are the source that an inheriting entity cites, but the provider does not score the customer's assessment.
- Published SRM: The provider's SRM, or HITRUST's baseline template where no provider SRM exists, sets the starting point for each request.
- Validated results: The provider's current HITRUST assessment is the source of the inherited scores, so its certification status must remain valid.
- Request handling: The provider enables external inheritance in MyCSF, accepts its terms and processes customer requests within the limits it publishes.
- Scope statements: The provider states which services, regions and environments its certification covers, and which it excludes.
- Customer communication: The provider tells customers about changes to its assessment or SRM that could affect inherited requirements.
Confirm with the provider which assessment version and scope its SRM references before relying on it.
An implementation partner such as DeployOpen works for the customer, where engaged, to prepare the customer's own systems, documentation and evidence. It can build the controls the customer retains, collect and organize evidence for the retained requirements and help map SRM entries to the customer's actual configuration. The partner does not own the customer's controls, does not decide inheritance weights and does not issue reports or certificates.
- System preparation: Configuring and hardening the customer's self-hosted platforms so retained controls can be demonstrated.
- Documentation: Drafting procedures, system descriptions and rationale narratives for the customer to review and adopt.
- Evidence collection: Setting up logging, access records and change histories that the customer's own team owns after handover.
- Gap work: Identifying retained requirements with no evidence and remediating them before the assessment window.
- Scope boundaries: Written scope defines which SRM entries the partner touches. Work outside that scope stays with the customer.
Ask any partner to state in writing which evidence it prepares and which the customer must produce itself.
Only an Authorized HITRUST External Assessor organization can perform a validated assessment submitted for certification, and HITRUST performs central quality assurance before issuing reports. The assessor tests the customer's controls, validates the inheritance rationale for each partial inheritance and scores the assessment. The assessor's independence matters: the same firm cannot both prepare the evidence and be the party that validates it without the rules that govern that relationship.
- Rationale validation: The assessor checks that each claimed weight and the documented reasoning match the SRM and the provider's validated results.
- Scoring: The assessor scores each requirement and the assessment as a whole in the fieldwork window, which is at most 90 days for e1, i1 and r2.
- Testing retained controls: The assessor tests the evidence for every requirement the customer retains, not the SRM itself.
- Quality assurance: HITRUST reviews the submission before any report or certificate is issued.
- Independence checks: The assessor and any preparation firm should document how their roles were kept separate.
Confirm the assessor is on HITRUST's current list of authorized organizations before contracting.
Questions buyers ask about HITRUST SRMs
Can a HITRUST shared responsibility matrix replace evidence in my assessment?
No. An SRM shows which requirements a provider can cover and where responsibility splits between you and the provider, but it cannot be used as scoring evidence. The HITRUST Assessment Handbook says inheriting entities use the provider's SRM, or HITRUST's baseline SRM template when no provider SRM exists, to identify inheritable requirements. For any requirement you inherit, the External Assessor still needs the provider's validated assessment results or other acceptable support. For every requirement you keep, you must produce your own evidence, such as configurations, logs, tickets, policies and records of operation. Treat the SRM as a map for planning, not as a document an assessor will score.
Which SRM should we use if our cloud provider has not published one?
Use HITRUST's baseline SRM template, which HITRUST offers as a free download alongside SRMs for major providers. Complete it with the provider's actual responsibilities for the services you use, drawing on the provider's contracts, security documentation and written answers to your questions. Ask the provider directly whether it has an SRM covering the in-scope services, since a provider-specific SRM is the preferred starting point when one exists. Where you cannot confirm that the provider handles a control, record it as your responsibility until the provider confirms otherwise. Keep the completed template, the provider's written answers and the date you received them, because the assessor will ask how each responsibility was determined.
How much of a HITRUST assessment can inheritance actually cover?
HITRUST states that organizations can inherit as much as 70% to 85% of requirements in HITRUST assessments from participating cloud service providers, according to its Shared Responsibility and Inheritance Program page. The figure is an upper bound that depends on the provider, the services you run on it and how much of your environment sits on those services. It does not describe every organization. Areas that stay with you typically include your information protection program, governance and policies, and oversight of your own third parties, as HITRUST's example for Oracle Cloud Infrastructure shows. Ask your assessor to walk through the SRM for your exact architecture before you plan around any percentage, and budget your own evidence work on the requirements that remain.
What must our organization still produce when we inherit requirements?
Several things remain yours even when a provider covers much of the control. Under partial inheritance, shared requirements need a weight percentage for each side and a documented rationale that the assessor validates, so you must write and defend that split. You also need evidence for your configurations of the provider's services, including identity and access settings, encryption choices, network rules and logging you enable. Governance, policies, risk management, workforce controls and your own vendor assurance stay with you. Full inheritance applies only when a requirement is entirely outsourced to the provider, so most cloud-based requirements will be partial. Build an evidence register that maps each requirement to its owner, its evidence source and its review date before fieldwork starts.
Can an implementation partner help us map requirements to the SRM?
Yes. An implementation partner can compare your architecture with the provider's SRM, identify which requirements appear inheritable, draft the responsibility split and prepare the evidence packs for the parts you own. DeployOpen works this way: it plans, implements and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, and it prepares systems, controls and evidence for assessment under a fixed scope agreed in writing. A partner cannot decide what the assessor will accept, cannot confirm what a cloud provider covers without the provider's documents, and cannot issue a HITRUST report or certification. Only an Authorized HITRUST External Assessor performs validated assessments submitted for certification, and HITRUST performs quality assurance before reports are issued. Your organization still owns every control and every inheritance decision.
How often should we recheck our SRM against the provider's current version?
The supplied sources do not set a fixed interval, so confirm the cadence with your provider and your assessor. As a working practice, check the SRM version and date against the provider's current published version before each inheritance request, before assessment fieldwork and before any recertification. Also recheck when the provider announces service changes, new regions or new managed components, and when HITRUST releases a new CSF version, because an SRM may need to reflect updated requirement text. HITRUST's current CSF version is v11.9.0, which is available in MyCSF from September 24, 2026. Record each check in your evidence register with the version reviewed, the reviewer and any requirements whose responsibility changed.
How DeployOpen prepares your side of an SRM-based assessment
DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so the requirements your SRM assigns to you have systems and evidence behind them. We prepare your side of the matrix and the evidence an independent External Assessor will review, while your organization keeps ownership of its controls and the assessor issues the results.
How we scope
- Engagements are fixed-scope, with the in-scope SRM rows, platforms and deliverables agreed in writing before work starts.
- We map which requirements your provider's SRM covers and which parts stay with your team as customer responsibilities.
- We confirm with you and your assessor which provider SRM version and HITRUST CSF version the scope relies on.
How we build
- We configure and harden the self-hosted platforms behind the customer-side requirements your SRM leaves to you.
- We set up logging, access control and backup routines so each customer-side requirement produces evidence an assessor can sample.
- We test the configured controls against the agreed scope before the assessor's fieldwork begins.
How we hand over
- We document each customer-side requirement with its configuration, owner, procedure and the evidence location.
- We deliver an evidence register that ties each requirement to artifacts and the SRM rows they support.
- We walk your team through the handover so your staff can maintain the controls and answer assessor questions.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the fixed-scope work ends.
- A retainer can keep SRM rows, evidence and configurations current when your provider updates its matrix or HITRUST releases a new CSF version.
- Support questions about the scope or evidence can be raised with us, while the assessor's findings remain the assessor's to issue.
