Why healthcare buyers confuse HIPAA, HITRUST, and SOC 2
Walk through the security or compliance page of almost any healthcare SaaS vendor and you are likely to see all three: a HIPAA compliance statement, a HITRUST certification badge, and a SOC 2 Type II seal. They appear together, which implies they are related. But they describe different things at different layers of the compliance and assurance landscape.
The confusion is understandable. Vendors have commercial incentives to present every credential they hold. Procurement teams often lack the time to distinguish between a regulatory obligation, a certifiable framework, and an independent attestation. And the three genuinely do overlap: HITRUST maps to HIPAA requirements, and SOC 2 controls can support HIPAA safeguards. But overlap is not equivalence, and a badge on a website is not the same as evidence that a specific product handling your patient data is secure and compliant.
The three-way comparison starts here.
| Dimension | HIPAA | HITRUST | SOC 2 |
|---|---|---|---|
| What is it? | U.S. federal law | Private certifiable security and compliance framework | Independent attestation standard (AICPA) |
| Primary purpose | Protect PHI/ePHI; enforce privacy, security, breach notification | Risk-based assurance across controls mapped to 60+ frameworks | Evaluate and report on a service organization's controls |
| Healthcare-specific? | Yes, specifically | Originally yes; now multi-industry | No, applies to any service organization |
| Regulatory requirement? | Yes, where applicable | No | No |
| Certification issued? | No. HHS does not issue a HIPAA certification | Yes, via authorized external assessor | No. A SOC 2 report is an attestation, not a certification |
| Independent assessment? | No standardized third-party audit; OCR investigates complaints/breaches | Yes, required for certification | Yes, by a licensed CPA firm |
| What does it help demonstrate? | That an organisation has addressed applicable HIPAA requirements | Risk-based control implementation, validated against a defined control set | That defined controls were designed and/or operated effectively during the assessment period |
| Typical buyer concern | Is the vendor legally obligated to protect our PHI? | Has the vendor passed a rigorous, validated security assessment? | Has an independent auditor reviewed and tested the vendor's controls? |
HIPAA, HITRUST, and SOC 2 explained
HIPAA
The Health Insurance Portability and Accountability Act (HIPAA) is U.S. federal law. It applies to covered entities, which include health plans, healthcare clearinghouses, and healthcare providers that transmit health information electronically, and to their business associates, which are entities that create, receive, maintain, or transmit protected health information (PHI) on behalf of a covered entity.
HIPAA's three principal rules for healthcare buyers to understand are the Privacy Rule (governing permitted uses and disclosures of PHI), the Security Rule (requiring administrative, physical, and technical safeguards for electronic PHI, or ePHI), and the Breach Notification Rule (requiring notification of affected individuals and HHS following a breach of unsecured PHI).
The Security Rule requires covered entities and business associates to conduct risk analysis, implement risk management, and apply appropriate safeguards, some of which are "required" and some "addressable" (meaning they must be implemented or an equivalent alternative documented). HIPAA does not prescribe exactly how to implement safeguards; it sets requirements that organisations must meet based on their specific environment and risk.
What "HIPAA compliant" actually means: HHS and its Office for Civil Rights (OCR) do not issue a HIPAA certification. No government body awards a badge confirming that a vendor is generically HIPAA compliant. When a vendor says it is "HIPAA compliant," it is describing its internal assessment that its practices, policies, and technical controls satisfy applicable HIPAA requirements. The claim is self-asserted unless supported by a Business Associate Agreement (BAA), independent security testing, or a third-party framework assessment.
The BAA is the contractual instrument that matters most in procurement. Any vendor that handles PHI on behalf of a covered entity must sign a BAA before receiving access to that data. A vendor that refuses to sign a BAA is not a viable choice for PHI-related workloads.
HITRUST
HITRUST Alliance is a private organisation that developed the HITRUST Common Security Framework (CSF), a certifiable security and risk management framework that maps controls to more than 60 authoritative sources including HIPAA, NIST CSF, ISO 27001, PCI DSS, GDPR, and others.
As of 2026, HITRUST offers three primary assessment and certification tiers:
e1 (Essentials, 1-year): 43 foundational controls. Designed for lower-risk entities or those at the start of their compliance journey. Valid for one year. Provides a baseline level of assurance.
i1 (Implemented, 1-year): 182 controls focused on leading cybersecurity practices and current threat landscape. Valid for one year. Aimed at organisations needing a moderate-to-strong assurance level. Controls must have been operational for at least 90 days before validated assessment.
r2 (Risk-Based, 2-year): Tailored controls ranging from 200 to 800+ based on the organisation's risk profile, data volumes, regulatory scope, and system complexity. The most rigorous tier, requiring assessment across five maturity levels: Policy, Procedure, Implemented, Measured, and Managed. Valid for two years with an interim assessment after year one. HITRUST has selected r2 as the required certification for Qualified Health Information Networks (QHINs) under TEFCA.
HITRUST certification requires evidence validation by an authorized HITRUST External Assessor and a quality assurance review by HITRUST itself. Self-assessment alone is not certification. HITRUST CSF is currently at version 11.7.0 and is updated regularly to address new threats and regulatory changes.
HITRUST certification does not automatically mean HIPAA compliance. HITRUST maps to HIPAA requirements, so achieving HITRUST certification provides meaningful evidence of HIPAA-aligned controls. But HIPAA obligations are organisational and situational. Buyers should verify which HIPAA requirements a HITRUST certification addresses for a specific vendor's specific in-scope systems.
SOC 2
SOC 2 (System and Organization Controls 2) is an attestation standard developed by the American Institute of Certified Public Accountants (AICPA). It applies to service organisations that store, process, or transmit customer data. A SOC 2 examination is conducted by a licensed CPA firm and results in an auditor's report, not a certification.
SOC 2 evaluates controls against five Trust Services Criteria (TSC): Security (mandatory), Availability, Processing Integrity, Confidentiality, and Privacy. Organisations select which criteria to include beyond Security. A healthcare vendor handling PHI would typically include the Privacy and Confidentiality criteria in addition to Security.
SOC 2 Type I assesses whether controls are designed appropriately at a specific point in time. It is a snapshot and does not test whether controls operated effectively over a period. Type I is useful as a starting point but is of limited assurance value for enterprise procurement decisions.
SOC 2 Type II tests whether controls were designed appropriately and operated effectively over a defined examination period, typically six to twelve months. Healthcare buyers and enterprise procurement teams almost universally request Type II because it demonstrates sustained, tested control performance rather than a point-in-time design review.
SOC 2 does not equal HIPAA compliance. SOC 2 uses its own control framework (the Trust Services Criteria) and its own scope definition. Many SOC 2 controls map to HIPAA Security Rule requirements, but the mapping is not complete, and a SOC 2 report does not address PHI-specific obligations such as BAA requirements, patient rights under the Privacy Rule, or breach notification procedures.
The real difference: regulation vs framework vs attestation
The most important conceptual distinction is the layer at which each operates.
| Concept | HIPAA | HITRUST | SOC 2 |
|---|---|---|---|
| Primary role | Regulation with enforcement authority (OCR) | Certifiable risk and control framework | Independent attestation standard |
| What is assessed? | PHI handling practices, safeguards, policies, procedures | Controls mapped to a defined set (e1/i1/r2) across security, privacy, and risk domains | Controls relevant to selected Trust Services Criteria over an examination period |
| Who relies on it? | HHS/OCR (enforcement); covered entities; patients | Buyers seeking structured, validated security assurance, especially in healthcare | Buyers needing independent, auditor-issued evidence of control effectiveness |
| What evidence does a buyer receive? | BAA; vendor's self-attestation of compliance; policies if requested | HITRUST certification letter/report for a defined scope | SOC 2 report issued by CPA firm covering defined scope and period |
| What does it not prove? | That controls are rigorously implemented or independently tested | That the vendor is HIPAA compliant across all obligations or that out-of-scope systems are covered | That the vendor is HIPAA compliant; that out-of-scope systems or periods are covered |
Does SOC 2 mean HIPAA compliant?
No. SOC 2 evaluates controls against the AICPA's Trust Services Criteria, which are not the same as HIPAA's required and addressable safeguards. SOC 2 can support HIPAA compliance by demonstrating that many security controls are designed and operating effectively. But SOC 2 does not address all HIPAA requirements, does not require a BAA framework, and does not cover PHI-specific obligations such as patient access rights under the Privacy Rule or breach notification timing under the Breach Notification Rule.
Does HITRUST mean HIPAA compliant?
Not automatically, for two reasons. First, HITRUST certification covers a specific in-scope environment. A vendor certified for one product or environment is not automatically HITRUST-certified across its entire platform. Second, HITRUST maps to HIPAA but is not administered by HHS. HIPAA compliance is an organisational obligation determined by applicable law, not a framework certificate. A HITRUST-certified vendor still needs to satisfy all HIPAA requirements applicable to its specific role as a covered entity or business associate.
Does HIPAA compliance mean the vendor is secure?
Not necessarily. HIPAA sets a minimum floor of required practices for PHI protection. It does not standardise the maturity, depth, or technical rigour of security controls. A vendor can be HIPAA-compliant and still have weak encryption practices, limited security monitoring, or no tested incident-response plan. Independent frameworks like SOC 2 and HITRUST exist precisely because HIPAA's requirements, while necessary, are not by themselves a sufficient security assurance programme.
What healthcare buyers actually learn from each claim
| Vendor claim | What it tells you | What you still need to investigate |
|---|---|---|
| "HIPAA compliant" | The vendor asserts it meets applicable HIPAA requirements. No independent validation is implied. | Ask for the BAA. Ask what specific PHI safeguards are in place. Request security policies and risk assessment documentation. Ask whether the claim covers your specific use case. |
| "HITRUST certified" | An authorized HITRUST External Assessor has validated controls in a defined scope environment against the relevant HITRUST assessment tier (e1, i1, or r2). | Which tier (e1, i1, r2)? What specific products or environments are in scope? When was the assessment completed and when does certification expire? Does the scope cover your use case? |
| "SOC 2 Type I" | A CPA firm assessed that controls were designed appropriately at a point in time. No testing of operating effectiveness over a period. | This is a point-in-time design assessment only. Ask for Type II. Ask what Trust Services Criteria are covered. Ask what is in scope. |
| "SOC 2 Type II" | A CPA firm tested controls across a defined period and attested they operated effectively. Strongest independently issued assurance of the four claims listed here. | What period does the report cover? What criteria are included? Were there any exceptions? What systems and services are in scope? What complementary user entity controls (CUECs) are required from your organisation? |
Scope is the most important procurement question
Every compliance claim, whether HIPAA, HITRUST, or SOC 2, applies to a defined scope. That scope may include only specific products, specific cloud environments, specific employee groups, specific geographies, or specific services. A vendor can be HITRUST r2-certified for its claims management platform and not certified at all for the patient-engagement module you are actually purchasing.
Report dates also matter. A SOC 2 Type II report covering a period that ended fourteen months ago is significantly less useful than a recent one. HITRUST e1 and i1 certifications are valid for one year. r2 certifications are valid for two years with a required interim assessment after year one. Ask for current documentation, not a badge linking to an outdated report. When reviewing a SOC 2 report, also check for exceptions, which are noted in the auditor's findings and indicate controls that did not operate effectively during the period. Even one or two exceptions in relevant control categories can be significant for healthcare data risk decisions. Finally, review complementary user entity controls (CUECs), which are responsibilities placed on the buyer's organisation that are necessary for the overall control environment to function as described.
How to evaluate a healthcare SaaS vendor
Consider a hospital evaluating two patient-engagement SaaS platforms. Both are plausible choices. Neither should be selected based on a compliance logo alone.
- Claims HIPAA compliance on website
- Will sign a BAA
- No SOC 2 report available
- Provides security policies on request
- No HITRUST certification
- Three years in market; 40 hospital clients
- HIPAA-focused security controls documented
- SOC 2 Type II (Security and Privacy criteria)
- HITRUST i1 certified
- Will sign a BAA
- Provides security documentation pack
- Five years in market; 120 hospital clients
Vendor B appears stronger on assurance credentials. But the buyer's decision should not stop at the credentials. The due-diligence process that follows is what determines actual risk.
Step 1: Confirm what data is handled. Does this vendor receive, store, or process ePHI? Which data elements? In what volume?
Step 2: Confirm HIPAA applicability. If PHI is involved, the vendor is a business associate. A BAA is required before data transfer begins.
Step 3: Review the BAA carefully. The BAA terms determine breach notification timelines, permitted uses of PHI, subprocessor obligations, and data destruction requirements. A BAA signed with weak terms provides limited protection.
Step 4: For Vendor A, request the underlying evidence. A vendor without SOC 2 is not automatically disqualified, particularly for smaller hospitals with lower-risk use cases. But request penetration test reports, security policy documentation, and evidence of risk assessments. Evaluate the quality of what you receive.
Step 5: For Vendor B, review the SOC 2 report directly. Confirm that the scope covers the patient-engagement product. Review the period. Review exceptions. Review CUECs. Confirm that the Privacy criterion is included given PHI is involved.
Step 6: For Vendor B, verify the HITRUST certification. Confirm the tier (e1, i1, or r2). Confirm the in-scope environment matches the product being purchased. Confirm the certification is current.
Step 7: Review subprocessors. Both vendors likely use third-party cloud infrastructure, email delivery, analytics, or support tools. Each subprocessor that handles PHI is also a business associate. Ask for a current subprocessor list and verify that BAAs are in place throughout the supply chain.
Steps 8-10: Assess security architecture, incident history, and business continuity. What encryption standards are used for PHI at rest and in transit? Has the vendor experienced a breach, and if so how did they respond and disclose? What is their recovery time objective for PHI-handling systems?
Which one does your organisation need?
| Business situation | HIPAA | HITRUST | SOC 2 |
|---|---|---|---|
| Vendor handles PHI as a business associate | Required where applicable | Valuable; not required | Valuable; not required |
| Small healthcare SaaS, PHI in scope | Required where applicable | Potentially valuable | Often expected by enterprise buyers |
| Enterprise healthcare SaaS | Required where applicable | Often expected by large health systems | Often expected |
| Platform processing significant PHI volumes | Required where applicable | Highly relevant; r2 may be expected | Highly relevant (Type II) |
| General SaaS with some healthcare customers (no PHI) | Not directly applicable | Depends on customer requirements | Often expected by enterprise buyers |
| Vendor selling to large health systems | Required where applicable | Frequently required in contracts | Frequently required in contracts |
| Vendor selling to QHINs (TEFCA) | Required | HITRUST r2 required by TEFCA | Valuable; not substitutable for r2 here |
Decision tree for buyers:
Does the vendor handle PHI on your behalf? If yes, HIPAA applicability must be confirmed, a BAA must be executed, and applicable safeguards must be in place. This is a legal obligation, not a preference.
Does your organisation or a contract require HITRUST certification? If yes, verify the certification tier and confirm it covers the product and systems involved. Some large health systems and payers now include HITRUST requirements directly in vendor contracts.
Do you need independently assessed evidence of control effectiveness over time? A recent SOC 2 Type II report from a licensed CPA firm provides this. For enterprise procurement, this is increasingly the minimum threshold for healthcare SaaS vendors accessing PHI, regardless of HITRUST status.
What to ask before signing the contract
Data and HIPAA
- Exactly what categories of PHI will you create, receive, maintain, or transmit on our behalf?
- Will you sign a Business Associate Agreement before receiving access to any PHI?
- Where is PHI stored, in which regions and cloud environments?
- How is PHI encrypted at rest and in transit, and what standards apply?
- How is access to PHI controlled and who within your organisation can access it?
- What is your process for notifying us of a breach involving our PHI, and within what timeframe?
- How is PHI securely deleted or returned at contract termination?
HITRUST
- Are you currently HITRUST certified, and at which assessment tier (e1, i1, or r2)?
- What specific systems, products, and environments are within the certification scope?
- What is the certification issue date and expiry date?
- Can you provide the certification letter and scope description?
- Is the product we are purchasing within the certified scope?
SOC 2
- Is the report Type I or Type II, and which Trust Services Criteria are included?
- What examination period does the report cover?
- What systems and services are included in the scope?
- Were there any exceptions noted in the auditor's findings?
- What complementary user entity controls are identified, and do they create obligations for our organisation?
- Can you provide us with the full SOC 2 report under NDA?
General security and operational risk
- Who are your current subprocessors that may access or handle our PHI?
- Do you have executed BAAs with all subprocessors that handle PHI?
- What is your documented incident response process and who is the notification contact?
- What are your backup and disaster-recovery capabilities for PHI-handling systems?
- When was your most recent penetration test conducted and by whom?
- Have you experienced any security breaches or OCR investigations? If so, provide details.
Common mistakes and cost considerations
The ten most common healthcare compliance procurement mistakes
1. Treating HIPAA as a certification. HHS does not issue a HIPAA certification. A vendor claiming to be "HIPAA certified" is using a phrase HHS does not recognise. The meaningful question is whether the vendor operates appropriate safeguards and will sign a BAA.
2. Assuming SOC 2 equals HIPAA compliance. SOC 2 covers information security controls evaluated against AICPA Trust Services Criteria. It does not address all HIPAA requirements and does not demonstrate PHI-specific obligations are met.
3. Assuming HITRUST eliminates HIPAA obligations. HITRUST certification demonstrates validated control implementation against a mapped framework. HIPAA obligations remain regardless of HITRUST status. The BAA must still be executed.
4. Looking only at compliance logos, not underlying documentation. Website badges are not evidence. Request the actual SOC 2 report, certification letter, and BAA template.
5. Ignoring scope. A SOC 2 or HITRUST certification that does not cover the specific product you are purchasing provides no relevant assurance for that product.
6. Ignoring report dates. A SOC 2 Type II report covering a period that ended more than twelve months ago, or a HITRUST certification that has expired, may no longer reflect the vendor's current control environment.
7. Not reviewing exceptions in SOC 2 reports. The auditor's findings section of a SOC 2 report documents any exceptions. Even a small number of exceptions in high-risk control areas is significant information.
8. Ignoring subprocessors. The vendor's subprocessors who handle PHI are also business associates. Ask for a complete list and verify BAA coverage throughout the supply chain.
9. Forgetting to execute the BAA before data access begins. PHI must not flow to a business associate before a BAA is in place. This is a HIPAA requirement, not a formality.
10. Treating certification as a security guarantee. No certification, attestation, or compliance programme guarantees that a vendor is secure or that a breach will not occur. It provides evidence of control maturity at a point in time or over a period. Risk assessment, not badge-counting, determines vendor suitability.
Cost and business considerations
Each programme involves meaningful investment. Published estimates and market data suggest the following ranges, though actual costs vary significantly by organisation size, scope, system complexity, and existing maturity:
HIPAA compliance programme: Establishing a HIPAA compliance programme, including risk analysis, policy and procedure development, training, security controls, and BAA management, involves ongoing personnel time and technology investment. Organisations without an existing security programme may require significant upfront investment in access controls, encryption, audit logging, and monitoring infrastructure.
HITRUST readiness and certification: HITRUST certification involves an authorised External Assessor engagement (typically $30,000 to $150,000+ depending on tier and scope), MyCSF platform fees, internal resource investment for evidence preparation (controls must operate for at least 90 days before assessment), and remediation of gaps identified during readiness. HITRUST r2 certifications at enterprise scope are typically at the higher end of this range. The process typically takes 9 to 12 months from initial readiness to certification.
SOC 2 readiness and examination: SOC 2 Type II examination costs from a CPA firm typically range from $20,000 to $80,000+ depending on scope, criteria selected, and firm. GRC platform costs (Vanta, Drata, Secureframe, Thoropass) add $10,000 to $40,000 annually. Readiness work, including gap analysis, control implementation, policy development, and evidence collection, adds further cost. The overall investment for a first Type II engagement, including readiness preparation, is typically $40,000 to $150,000+ for a mid-sized SaaS organisation.
These are cost indicators, not universal benchmarks. Organisations with existing mature security programmes and GRC infrastructure will face lower incremental costs. Ongoing maintenance, monitoring, and annual re-examination represent recurring costs beyond initial certification.
Healthcare compliance and cybersecurity vendor report
The following companies offer verified capabilities in HIPAA compliance, HITRUST assessment and certification support, SOC 2 examination and readiness, and healthcare cybersecurity. This is not a ranked list and inclusion does not imply endorsement. Capabilities are verified from official company documentation as of mid-2026. Verify current scope and offerings before engaging any provider.
Suggested additional providers to evaluate based on organisational needs: Tevora (cybersecurity and compliance advisory, SOC 2 and HITRUST capabilities), Securis360 (SOC 2 readiness, HIPAA, HITRUST consulting, penetration testing), and Aptible (HIPAA-ready infrastructure platform for digital health startups, BAA-by-default hosting).
Final takeaway: the right procurement question
HIPAA tells you about applicable healthcare regulatory obligations and the legal framework governing PHI. HITRUST provides a certifiable, risk-based control assurance framework validated by an authorized external assessor. SOC 2 provides independently issued attestation over defined controls evaluated against selected Trust Services Criteria during a specific examination period.
The wrong procurement question is: "Which badge is best?" A HITRUST r2 certification on a system that does not cover the product you are buying provides no relevant assurance. A SOC 2 report with significant exceptions in access-control criteria is not equivalent to a clean report. A HIPAA compliance claim without a BAA is an assertion without teeth.
The right procurement question is: what specific evidence do I need to determine whether this vendor can safely and reliably handle our healthcare data? The answer requires reviewing actual documentation, scoping compliance claims to your specific use case, executing appropriate legal agreements, and treating compliance credentials as inputs to risk assessment rather than substitutes for it.