Does a SOC 2 satisfy a healthcare customer's HIPAA requirements?
A SOC 2 is not a HIPAA certification, and it does not discharge a healthtech vendor's HIPAA obligations on its own. A SOC 2 is an independent report on controls relevant to the Trust Services Criteria, issued by a CPA firm after examination. It says nothing about whether the vendor complies with the HIPAA Security Rule. HHS is direct about the consequence: a business associate is directly liable to OCR for Security Rule failures, whatever report it holds. The HHS cloud guidance adds a point many vendors miss: a cloud service provider that stores ePHI is a business associate even if it holds only encrypted data and does not have the key. A vendor that hosts a customer's encrypted records therefore carries Security Rule duties even though its own staff never see the content.
Whether a SOC 2 satisfies a given customer depends on three things: the vendor's actual data flows, the terms of the business associate agreement, and what the customer's compliance team has written into its own vendor requirements. Start by mapping which ePHI the service creates, receives, maintains or transmits, and which subcontractors touch it. The BAA must require compliance with the Security Rule's Subpart C, flow the same requirements down to subcontractors, and require reporting of security incidents. A SOC 2 covers only the systems and criteria in its scope, so confirm that the in-scope system includes every environment where ePHI resides. Ask the customer's security team whether it accepts a SOC 2 as evidence, asks for a HIPAA-specific attestation, or requires its own questionnaire. Confirm these points with the customer and your examiner in writing before you promise that the report answers their questions.
What the business associate agreement must require for security
This table compares each security obligation that 45 CFR 164.314(a)(2)(i) requires a business associate agreement to contain against what the vendor must be able to show and where a SOC 2 report helps or falls short. Read it as a checklist for contract review: a SOC 2 covers the controls it tests, but the BAA also requires HIPAA-specific commitments that an attestation does not replace. The main takeaway is that a SOC 2 supports the security obligations but does not by itself satisfy the BAA.
| Obligation | What the vendor must be able to show | Where SOC 2 helps or does not |
|---|---|---|
| Comply with Subpart C of the Security Rule | Documented safeguards mapped to the administrative, physical and technical standards, with a risk analysis behind them | Helps for controls in scope, but the SOC 2 does not test every Subpart C implementation specification |
| Flow requirements down to subcontractors | A current list of subcontractors handling ePHI and signed compliant agreements with each one | Helps through CC9 vendor management criteria, but the SOC 2 does not confirm HIPAA-compliant subcontract terms |
| Report security incidents to the covered entity | A written incident response procedure, detection records and a timeline for notifying the covered entity | Helps through CC7 incident criteria, but the SOC 2 does not establish the contractual notice period |
| Report breaches of unsecured PHI | Evidence of breach assessment, documentation and notification steps tied to the BAA | Partial: the SOC 2 tests the process, while breach determination under HIPAA is a separate legal assessment |
| Written verification of technical safeguards every 12 months (proposed) | A process to produce written verification on request, aligned with the proposed rule in 90 FR 898 | Partial: a Type 2 report can support verification, but the proposed rule is not final and the SOC 2 is not the HIPAA verification itself |
| Return or destroy PHI at termination | Documented disposal procedure and a record of disposal for each covered entity | Helps through confidentiality and disposal criteria in C1, where in scope, but the SOC 2 does not confirm contractual return terms |
| Confirm the BAA matches the services in scope | A reconciliation of the BAA, the system description and the services covered by the report | Helps when the system description names the services, but the SOC 2 does not decide which services are business associate functions |
What a SOC 2 does and does not prove about HIPAA
A SOC 2 report tests controls against the Trust Services Criteria, which is a different yardstick from the HIPAA Security Rule. Each card below names one gap between the two and says how to confirm it before a customer relies on the report for HIPAA purposes.
The Trust Services Criteria are not the Security Rule
SOC 2 tests the controls you describe against the AICPA's Trust Services Criteria, while the HIPAA Security Rule sets its own standards and implementation specifications under 45 CFR 164.302 onward. A control can satisfy a common criterion and still leave a Security Rule specification unaddressed. Ask the customer which HIPAA standards they expect you to meet, then check each one against your control matrix rather than assuming the criteria cover it.
SOC 2 does not opine on legal compliance
AICPA staff FAQs on SOC 2 and SOC 3 engagements address whether a SOC 2 opinion covers compliance with laws and regulations, and the answer is that it does not give assurance on that. The auditor reports on whether controls were suitably designed and operating effectively against the criteria. Read the auditor's description of the engagement and the report's opinion wording, and do not accept a SOC 2 as proof that HIPAA obligations are met.
Risk analysis and HIPAA policies need separate mapping
The Security Rule requires a documented risk analysis and risk management process, along with policies and procedures tied to its safeguards. A SOC 2 risk assessment under CC3 may not be built to the Security Rule's scope, so it can miss ePHI assets and threats that a HIPAA analysis must cover. Build a separate map from each Security Rule safeguard to your policies, risk analysis and evidence, and confirm with the customer that the map meets their expectations.
Subcontractor BAAs need their own evidence
Under 45 CFR 164.314(a), a business associate must flow Security Rule requirements down to subcontractors through compliant contracts. A SOC 2 that carves out your hosting provider or analytics vendor as a subservice organization does not show that those subcontractors signed BAAs or meet the Security Rule. Inventory every subcontractor that touches ePHI, collect signed BAAs, and review each provider's own SOC 2 or HIPAA evidence.
The report scope may exclude the ePHI environment
A SOC 2 covers only the system described in management's description, and a vendor can scope out a product, region or data store that holds ePHI. Compare the system boundary in the description with where patient data actually flows, including backups, logs, support tooling and test environments. If the ePHI environment sits outside scope, ask for a separate examination, a SOC 2+ with HIPAA criteria, or direct evidence for that environment.
Direct liability is not transferred by the report
Business associates must comply with the Security Rule and are directly liable to HHS for Security Rule failures. A clean SOC 2 does not reduce that liability or replace the written verification of technical safeguards that the January 2025 proposed rule would require every 12 months. Confirm with counsel which obligations apply to your organization today, and track whether the proposed verification requirement becomes final.
When to add HIPAA criteria to a SOC 2 with SOC 2+
A standard SOC 2 tests the organization's controls against the AICPA 2017 Trust Services Criteria, with the common criteria CC1 to CC9 applying to every examination and any additional categories added only when they are in scope. The report describes the system and the controls over security, and the auditor expresses an opinion on those criteria. It does not state that the organization complies with HIPAA, because the examination does not test HIPAA's requirements as such.
- Who sets the scope: Management defines the system boundary and selects the categories. The auditor reviews that scope but does not choose it for the organization.
- What the report covers: Trust services criteria only, reported against the description criteria for the system.
- What customers still ask for: A business associate agreement, a HIPAA risk analysis, and evidence of Security Rule safeguards, which the SOC 2 may only partly answer.
- Common gap: Customers may read the report as a HIPAA attestation. Explain in the trust page which requirements the report does and does not address.
- Cost driver: Fewer categories and a narrower system boundary generally mean less testing.
Before choosing this option, confirm with key customers in writing whether a standard report satisfies their vendor review.
Some organizations keep the standard SOC 2 report but maintain a control matrix that maps each HIPAA Security Rule safeguard to the controls and trust services criteria that address it. The auditor tests the mapped controls as part of the normal examination, so the mapping is backed by tested evidence rather than a narrative. The report itself still reports on the trust services criteria, and the mapping is supporting material that customers can review.
- Mapping ownership: The organization writes and maintains the matrix. The auditor tests the controls, not the mapping's legal accuracy.
- Gaps to expose: Some Security Rule standards concern administrative duties, such as contract management and workforce sanctions, that a SOC 2 may not test directly.
- Evidence reuse: Access reviews, logging and change records can serve both the SOC 2 and the HIPAA mapping if they are designed for both.
- Legal review: Ask counsel whether the mapping supports the representations in the business associate agreement.
- Currency: Update the matrix when the Security Rule changes, including the pending proposed rule, which was not final as of October 2026.
Ask the auditor whether the mapped controls will be tested in the examination period and how exceptions against them would appear in the report.
A SOC 2+ examination adds criteria or subject matter beyond the trust services criteria to the same report. The AICPA's October 2022 SOC 2 guide includes an illustrative report for this case. Management selects the additional criteria, and the auditor must agree that they are suitable and measurable and that the report users can rely on them. Because the criteria are defined by the organization, the report's conclusions apply only to what those criteria actually measure.
- Who decides: Management proposes the criteria and the auditor assesses their suitability. Customers can request criteria, but they do not make the final choice.
- Suitability test: The criteria must be objective enough for the auditor to test and specific enough for readers to understand the scope.
- Report structure: The additional criteria are presented alongside the trust services criteria and need a clear description of what was tested.
- Limits: A SOC 2+ opinion is not a HIPAA determination and does not make the organization compliant by default.
- Verification: Ask the auditor for a draft of the description and the criteria before fieldwork, and confirm how exceptions will be reported.
Confirm in writing that the auditor has accepted the HIPAA criteria for this engagement before the report is shared with any customer.
How a healthtech SOC 2 with HIPAA mapping is scoped and run
The sequence turns a vague request for SOC 2 and HIPAA assurance into a bounded system, mapped controls, tested evidence and a report that the auditor issues and the company shares under restricted use. Each phase produces a named output that the next phase depends on.
Define the system boundary around ePHI flows
The company lists every place electronic protected health information is created, received, maintained or transmitted, including production databases, integration interfaces, support tooling, backups, analytics exports and subcontractor services. Management, with the implementation partner, decides which components sit inside the system description and which are carved out as subservice organizations. The output is a written boundary diagram and inventory that the auditor agrees to before control design begins.
Map Security Rule standards to the criteria
The team builds a crosswalk that links each HIPAA Security Rule standard and implementation specification to the SOC 2 common criteria and any added categories in scope, such as availability or confidentiality. Gaps are recorded where the Security Rule asks for something the Trust Services Criteria do not name directly, such as specific contract flow-downs. The output is a mapping workbook reviewed by the company's privacy or compliance lead and, where possible, the auditor, with the caveat that the mapping supports assurance and does not replace a HIPAA risk analysis.
Prepare controls, policies and business associate contracts
The organization writes or updates its policies, assigns control owners and configures the technical safeguards that the matrix requires, such as access reviews, logging, encryption and incident handling. Business associate agreements with customers and subcontractor agreements are checked against the terms the Security Rule requires for security obligations, incident reporting and flow-down. The implementation partner prepares systems and evidence, but the company owns each control and signs the policies. The output is a control matrix with owners, populated policies and a contract register.
Collect and organize evidence before fieldwork
Control owners produce the records the matrix promises: access review sign-offs, joiner and leaver tickets, change approvals, vulnerability scan results, backup restore tests and training completions. Evidence is stored with dates, owners and a clear link to the control it supports, so that samples can be pulled quickly. Gaps found in this rehearsal are fixed or documented as known exceptions before the examination starts. The output is an evidence library that a reviewer can navigate without help from the engineer who produced it.
Select an independent CPA firm
The company requests proposals from CPA firms that perform SOC 2 examinations, asking each to explain how it will treat the HIPAA mapping, whether it has experience with healthcare customers and how it will handle ePHI samples without taking copies of patient data. Scope, period, deliverables and the engagement letter are agreed in writing. Only the independent firm issues the report; the implementation partner and any consultant do not. The output is a signed engagement letter and an agreed system description draft.
Run Type 1 or Type 2 fieldwork
For a Type 1, the auditor tests whether the controls are suitably designed and in place as of one date. For a Type 2, the auditor also tests operating effectiveness across an observation period, using samples and testing procedures set by the auditor's methodology. Management provides the written representations that the examination requires and answers exceptions with root cause and corrective action. The output is a set of documented test results, a list of any exceptions and a draft report that management reviews for accuracy.
Deliver the report under restricted use
The auditor issues the SOC 2 report with its opinion, the system description and the test results. Because a SOC 2 report is generally restricted in use, the company shares it only with customers and parties under an appropriate agreement, and may publish a general use SOC 3 for public distribution. Customers that also ask about HIPAA receive a clear statement of what the report covers and what remains a matter for their own risk analysis. The output is an issued report, a distribution record and a plan for the next examination cycle.
When customers ask for HITRUST instead of SOC 2
Some customers ask for HITRUST instead of SOC 2, and the choice is set by the customer's contract and procurement policy, not by a rule that applies to every HIPAA business associate. Large health system customers are the usual source of this request, so the first step is to read the security questionnaire or master agreement and find the exact assurance named. A SOC 2 is an attestation issued by an independent CPA firm against the Trust Services Criteria, while HITRUST describes its own certifiable framework. Confirm in writing which one the customer will accept, and whether a SOC 2+ report with HIPAA criteria, a HITRUST e1 or i1, or a broader HITRUST r2 is the document that satisfies the request.
HITRUST describes the i1 as a certification with a defined control set, testing by an external assessor and central HITRUST quality assurance, which contrasts with SOC 2 as an attestation where criteria are chosen by the service organization and the examined scope. The HITRUST e1 and i1 assessments are described on HITRUST's own pages, and the HITRUST vs SOC 2 comparison explains the difference in assurance type. Because the control set is fixed, a HITRUST assessment can require controls and evidence that a SOC 2 scope does not, so a team that already runs a SOC 2 should map its existing controls before estimating the gap. Ask the customer whether they require a specific HITRUST assessment type and whether the result must be a certification.
Before committing to HITRUST, confirm the details directly with HITRUST rather than relying on secondary sources. Ask HITRUST which assessment types are valid for the customer's request, which assessor and readiness licensee are eligible, and what the current assessment handbook requires. HITRUST lists external assessors and readiness licensees on its assessor directory, and the current assessment handbook sets out assessment mechanics. Ask both the customer and the assessor for the cost components, the one-time assessment fee versus the recurring certification and renewal costs, and whether a SOC 2 report can be reused to reduce testing effort. Do not assume a SOC 2 substitutes for HITRUST, or the reverse, until the customer confirms it in writing.
Choosing between a SOC 2, a SOC 2+ and a HITRUST assessment
This table compares the three attestation or assessment paths a healthtech vendor is most often asked for, by what the customer requests, what evidence each produces, who issues it and when it fits. Read it as a decision guide: confirm what your customers actually require in their contracts before choosing, because a SOC 2 report alone does not establish HIPAA compliance.
| Option | What it produces and who issues it | When it fits |
|---|---|---|
| SOC 2 Type 2 | An independent CPA report on the design and operating effectiveness of controls over a period, under the 2017 Trust Services Criteria. A CPA firm issues it. The report is restricted use. | Customers whose security reviews ask for SOC 2 generally, and where the controls you run are not yet mapped to HIPAA Security Rule specifications. |
| SOC 2+ with HIPAA criteria | A SOC 2 report that also addresses HIPAA Security Rule criteria or subject matter beyond the trust services criteria, using the AICPA's illustrative SOC 2+ format. A CPA firm issues it. The report is restricted use. | Customers that want assurance on HIPAA-specific safeguards in a format their auditors already understand, and where the contract names HIPAA safeguards as the subject. |
| HITRUST i1 | A certification against a defined control set, tested by an external HITRUST assessor and quality-assured centrally by HITRUST. HITRUST issues the certification after its review. | Customers whose vendor questionnaires or contracts name HITRUST, or who want a standardized, certifiable result rather than a flexible attestation. |
| HITRUST e1 or other HITRUST assessments | Validated assessments with a defined scope and external assessor testing, subject to HITRUST quality assurance. Confirm the assessment type and report terms with HITRUST before scoping. | Smaller or earlier-stage vendors, or customers that ask for a HITRUST result at a level below the full assessment. Confirm which level your customers accept. |
| Who controls the decision | Your customers' contracts, security questionnaires and procurement rules set the requirement. Your own HIPAA Security Rule program is required whichever report you hold. | Ask each customer in writing which report or assessment satisfies its vendor requirement before you commit budget. |
| What each report does not prove | None of these reports is a HIPAA compliance determination. Customers and OCR still look to your risk analysis, BAA obligations and Security Rule safeguards. | Use the report as evidence of controls, and keep your HIPAA documentation separate and current. |
Questions healthtech vendors ask about SOC 2 and HIPAA
Does a SOC 2 report satisfy HIPAA requirements?
No. A SOC 2 report does not satisfy HIPAA by itself. HIPAA has no certification or attestation that replaces the Security Rule, and a cloud provider or software vendor that handles ePHI for a covered entity is a business associate in its own right. The SOC 2 examination tests whether controls operated against the 2017 Trust Services Criteria, which overlap with many Security Rule safeguards but are not the same list. A SOC 2 can give a customer useful evidence for its own HIPAA risk analysis, but the vendor still owns its Security Rule compliance and remains directly liable to OCR for Security Rule failures. Ask your customers which Security Rule requirements they want mapped to your controls, and have counsel confirm the mapping before you rely on it.
Can a business associate agreement reference our SOC 2 report?
A business associate agreement can point to a SOC 2 report, but it cannot replace the Security Rule terms the contract must contain. Under 45 CFR 164.314(a), the contract must require the business associate to comply with the Security Rule, flow the same requirements down to subcontractors, and report security incidents, including breaches of unsecured PHI, to the covered entity. A report reference is usually written as supporting evidence, with the customer's right to request current assurance spelled out. Check whether the report's scope covers the services the customer actually buys, and confirm the report's period and any exceptions before the customer relies on it. Your counsel should draft the BAA, and the customer's counsel will review it.
What must a SOC 2 scope include for ePHI?
The scope should include every system that creates, receives, maintains or transmits ePHI for customers, not only the production application. In practice this covers the application, databases, backups, storage buckets, logging and analytics pipelines, support tooling, and the cloud accounts that host them. The system description should state which Trust Services Criteria are in scope, and the security category is always included. Privacy and confidentiality criteria are commonly added when customers send personal health data, but they are an addition to the examination, not a substitute for HIPAA. Subservice organizations that store or process ePHI, such as hosting providers, need to be listed and their own reports reviewed. Confirm the boundary with your auditor early, because a scope that leaves out a data store is the most common reason a customer questions a report.
Is HITRUST required if we already have a SOC 2?
HITRUST is not required by HIPAA, and a SOC 2 alone is usually enough for many customers. Some health systems and payers ask for HITRUST because their own procurement policies specify it. HITRUST describes the i1 as a certification with a defined control set, external assessor testing and central quality assurance, while SOC 2 is an attestation with flexible criteria chosen by the service organization. Ask each customer whether a SOC 2 with HIPAA-related criteria, a HITRUST e1 or i1, or a broader HITRUST r2 is written into its vendor requirements. Choosing HITRUST changes the assessor, the control set and the cost, so the decision should be driven by contract language rather than by general preference.
What work does a SOC 2 for healthtech need from our internal staff?
The engagement needs named owners across engineering, security, operations, HR and legal, because a SOC 2 relies on evidence that only your staff can produce. Engineering owns configuration, access, logging and change records. HR owns background checks, training and joiner and leaver records. Legal or operations owns vendor contracts, BAAs and incident notification records. Expect the most time from whoever runs the control matrix and answers the auditor's evidence requests, and plan for that person to be available during fieldwork and during the Type 2 observation period. Cost depends on how many systems hold ePHI, how many controls you already operate, and how much of the preparation an outside firm carries. Ask any partner to show a written scope and a list of deliverables before work begins.
Do the pending HIPAA Security Rule changes affect our SOC 2 plan?
The changes are proposed, not final, so they should shape your plan without yet setting its requirements. The January 2025 proposed rule (90 FR 898) would require business associates to give covered entities written verification of their technical safeguards at least once every 12 months. As of October 2026 it was still a proposal. A SOC 2 Type 2 with a current period already gives customers a point-in-time and period-based view, but it is not the same as the verification the proposal describes, and the final text may differ. Plan for a recurring evidence cycle, keep control evidence organized by Security Rule requirement, and track the final rule through the Federal Register. Ask counsel how any final version would apply to your existing BAAs.
Can our team run the SOC 2 for healthtech internally?
Many healthtech companies run the internal work themselves and buy outside help for specific gaps. The organization owns its controls and its evidence. An implementation partner can prepare systems, controls and documentation, but only an independent CPA firm issues the SOC 2 report. Internal teams usually handle policy ownership, access reviews and incident records, while outside help may cover control design, technical hardening, logging setup or evidence collection in self-hosted tools. DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside a client's own infrastructure and prepares evidence for assessments, but it does not issue reports. Agree the division of work in writing, and confirm with your auditor which parts they will test.
How DeployOpen prepares healthtech systems and evidence for a SOC 2
DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks, and prepares the controls and evidence that a SOC 2 examination will test. We do not issue audit reports or attestations; the independent CPA firm performing the examination does.
How we scope
- We agree a written, fixed scope before work starts, naming the systems, environments and trust services categories in play.
- Scope covers which ePHI flows, subcontractors and subservice organizations, and the BAA obligations the controls must support.
- Ongoing support, upgrades and continuous testing can be added as a retainer once the written scope is agreed.
How we build
- We implement and harden the self-hosted platforms, access controls, logging and change workflows that the common criteria depend on.
- We configure encryption, multi-factor authentication and backup settings and document how each one is operated and reviewed.
- We run security testing of applications, APIs and infrastructure so that exceptions are found and fixed before the examination window.
How we hand over
- We deliver a control matrix mapping each in-scope criterion to the system, owner and evidence source that supports it.
- We document system descriptions, runbooks and evidence collection steps so the client's team can produce records for the auditor.
- We provide training and walkthroughs so staff can explain their controls during fieldwork, while the auditor retains sole responsibility for testing.
How we support
- Support can continue after the report is issued, covering upgrades, monitoring between audits and changes to the platform.
- We can revisit the control matrix when systems change, so evidence stays consistent for a Type 2 observation period.
- Ask us to confirm the boundaries of our role in writing, including which deliverables sit with your CPA firm and which with your team.
