HIPAA vs HITRUST: Which Do You Actually Need?

HIPAA vs HITRUST: Which Do You Actually Need?

TL;DR

• HIPAA is United States federal law. Any organization that touches protected health information (PHI) must comply, regardless of size.
• HITRUST is a voluntary private certification. It proves to enterprise buyers that your security program meets HIPAA and dozens of other frameworks simultaneously.
• There is no such thing as an official HIPAA certificate. OCR enforces HIPAA after the fact, through breach investigations and audits.
• Most healthcare SaaS companies need HIPAA compliance from day one and pursue HITRUST only when a specific hospital or payer contract requires it.
• The two are not alternatives. A HITRUST-certified organization is still fully subject to HIPAA enforcement.

Who this is for

This article is for software vendors, managed service providers, and digital health startups that handle PHI and need to understand which compliance requirements actually apply to them. It covers the structural difference between a regulation and a certification framework, when each becomes relevant, and how the two layer together in practice.

What HIPAA actually is

The Health Insurance Portability and Accountability Act of 1996 is United States federal statute. It applies to three categories of covered entities: healthcare providers who transmit health information electronically, health plans, and healthcare clearinghouses. It also applies to business associates, meaning vendors and service providers that handle PHI on a covered entity's behalf. The full text is codified at 45 CFR Parts 160 and 164.

HIPAA imposes requirements through three rules:

The Privacy Rule governs who may access PHI and under what conditions. It limits uses and disclosures of PHI to those permitted or required by law, gives patients rights over their records, and requires covered entities to provide notices of their privacy practices.

The Security Rule requires covered entities and business associates to protect electronic PHI (ePHI) through administrative, physical, and technical safeguards. Administrative safeguards include things like designated security officials, workforce training, and access management procedures. Physical safeguards cover facility access controls and workstation policies. Technical safeguards cover access controls, audit controls, integrity protections, and transmission security.

The Breach Notification Rule requires covered entities to notify affected individuals, HHS, and in some cases the media when unsecured PHI is breached. Individuals must be notified within 60 days of discovering a breach. Breaches affecting 500 or more individuals in a state or jurisdiction require simultaneous media notification and immediate reporting to HHS.

HIPAA is enforced by the Office for Civil Rights (OCR) at the Department of Health and Human Services. Enforcement is typically triggered by a reported breach, a patient complaint, or an OCR compliance review. Penalties are tiered by culpability. The 2024 inflation-adjusted figures published in the Federal Register set the per-violation range at $137 (unknowing violations) to $2,067,813 per year (willful neglect not corrected, per violation category).

HIPAA does not issue certificates. There is no government-issued document confirming an organization has passed a HIPAA compliance review. OCR audits assess compliance after the fact. That absence of a credential is what creates the problem HITRUST solves.

What HITRUST actually is

The HITRUST Alliance is a private organization that publishes the HITRUST Common Security Framework (CSF), a control library that consolidates requirements from over 70 standards and regulations, including HIPAA, NIST 800-53, ISO/IEC 27001, PCI DSS, and GDPR. As of Version 11.4 (released December 2024), the framework uses a threat-adaptive engine that incorporates current breach data and threat intelligence into control requirements.

When an organization pursues HITRUST certification, a HITRUST-authorized external assessor evaluates the organization's controls against the CSF, and HITRUST validates the assessor's report. The result is a time-bound certificate stating the organization's security and privacy program has been evaluated by an independent third party to a defined standard.

HITRUST offers three certification tiers, each with a different control count and validity period:

e1 (Essential): 44 core controls. Valid for one year. Designed for lower-risk vendor relationships and organizations beginning their security program. Hospital systems generally do not accept e1 as sufficient for high-risk vendor categories.

i1 (Implemented): 182 control requirements. Valid for one year. The common path for growth-stage SaaS companies that need to demonstrate a working security program to mid-market enterprise buyers.

r2 (Risk-based): The highest tier. Control counts are tailored by scope and risk profile. Valid for two years with an interim assessment in year two. This is what enterprise health buyers, hospital systems, and large payers typically mean when they say "we require HITRUST."

HITRUST manages the assessment workflow through its MyCSF platform, a SaaS tool that handles evidence collection, control inheritance, and reporting. HITRUST states that organizations can inherit validated controls from certified cloud providers, reducing applicable effort by up to 85% for those controls.

HIPAA vs HITRUST: the side-by-side

The clearest framing: HIPAA specifies what you must do. HITRUST gives buyers evidence that you did it.

When HIPAA compliance alone is enough

HIPAA-only is workable in several situations:

• Your buyers are small medical practices, dental groups, or independent clinics. These organizations typically accept a signed Business Associate Agreement (BAA) plus a HIPAA self-attestation, not a third-party certification.
• You are a covered entity selling services to other small covered entities, not into large hospital systems or payer networks.
• You are at an early stage where enterprise healthcare deals are not on the immediate roadmap.
• Your customer contracts and BAA templates make no reference to HITRUST or any third-party certification.

For organizations in this group, the work is building and maintaining the actual HIPAA program: a documented risk assessment, signed BAAs with all subcontractors who touch ePHI, workforce training with completion records, written policies for all required administrative safeguards, and technical controls including encryption and audit logging. See the HIPAA risk assessment guide for methodology detail and the HIPAA training requirements post for workforce obligations.

The cost of staying HIPAA-only is relatively low. The cost of a deficient program is not. OCR's published resolution agreements include multimillion-dollar settlements for violations tracing back to missing risk assessments, unencrypted portable devices, and inadequate BAAs.

When HITRUST becomes necessary

HITRUST is effectively required when a specific buyer's procurement process demands it. The common triggers:

• A hospital system or integrated delivery network includes HITRUST r2 (or i1) as a prerequisite in their vendor risk assessment questionnaire.
• A large payer's security team cites HITRUST in the master services agreement or security addendum.
• A large pharma company's third-party risk team specifies a HITRUST certification tier in its vendor requirements.
• Your contracts involve high volumes of patient records or integration with clinical systems, putting you in a high-risk vendor category where buyers require third-party validation.

The trigger is almost always external. Organizations do not typically pursue HITRUST because they have decided they want to. They pursue it because a specific deal requires it. The question to ask procurement teams directly is: "Which HITRUST tier, and is i1 acceptable or do you require r2?" The answer varies by buyer and by the nature of the data access involved.

HITRUST does not replace HIPAA

A HITRUST-certified organization remains fully subject to HIPAA enforcement by OCR. The HITRUST certificate is evidence of a strong security program. HITRUST documentation can support a response to an OCR investigation. It does not create legal immunity. If a breach occurs, OCR will still investigate. The HITRUST r2 report may be favorable evidence, but it is not a defense.

Practical consequences of this layering:

• A HITRUST r2 assessment produces evidence that addresses most HIPAA Security Rule requirements. You still need separate Privacy Rule documentation (notices of privacy practices, patient rights procedures) that HITRUST does not fully address.
• A HITRUST i1 certification covers the most common HIPAA Security Rule controls, but Privacy Rule gaps remain.
• Signed BAAs are required by HIPAA law regardless of HITRUST tier. HITRUST does not create or replace business associate agreements.

For BAA requirements, see the HIPAA business associate agreement guide.

How HITRUST relates to SOC 2 and ISO 27001

For companies already holding SOC 2 Type 2, the path to HITRUST i1 is shorter than starting from scratch. A substantial portion of HITRUST i1 controls overlap with SOC 2 Type 2 controls when SOC 2 was scoped to include the Security, Availability, and Confidentiality criteria. The SOC 2 control documentation carries over. The additional HITRUST work concentrates in two areas: privacy controls that SOC 2 does not require (mapping to HIPAA Privacy Rule obligations), and the maturity scoring methodology that HITRUST uses and SOC 2 does not.

HITRUST rates each applicable control on a five-point maturity scale: Policy (documented), Procedure (step-by-step), Implemented (deployed), Measured (monitored), Managed (continuously improved). SOC 2 Type 2 asks whether a control existed and operated effectively during the audit period. HITRUST asks how mature the control is across all five dimensions. This maturity model is the primary reason HITRUST r2 is harder than SOC 2 Type 2 even when the control coverage overlaps.

ISO 27001 covers a similar range. An ISO-certified ISMS provides a head start on HITRUST CSF controls, particularly in the risk management, asset management, and access control domains. See SOC 2 vs ISO 27001 for the choice between those two as a first certification, and the SaaS compliance frameworks guide for stacking strategy across multiple programs.

Decision framework: which path fits your situation

Five questions in sequence:

1. Do you handle PHI? If yes, HIPAA applies now. Size does not matter. There is no revenue threshold or patient volume below which HIPAA does not apply.

2. Who are your current and near-term buyers? Small practices and clinics rarely require more than a BAA and self-attestation. Hospital systems, large payers, and large pharma routinely do.

3. What does procurement actually ask for? Request the vendor risk questionnaire or security addendum from your current enterprise prospects before committing to a certification path. Many ask for SOC 2 Type 2 first. HITRUST r2 is common for clinical system integrations and high-volume PHI access.

4. What is your existing control posture? Starting HITRUST from a bare HIPAA program takes longer and costs more than building on an existing SOC 2 program. Most practitioners recommend building the HIPAA program, then adding SOC 2, then adding HITRUST in that sequence.

5. Can the deal value justify the cost? HITRUST r2 is a substantial investment in assessor fees, platform costs, and internal time. The decision to pursue it should be tied to a specific contract or pipeline segment where it opens otherwise-closed deals.

Per-persona recommendation

Healthcare SaaS, early stage, selling to clinics and small practices: Build the HIPAA program now. A signed BAA template, a risk assessment, documented policies, and workforce training records satisfy typical buyers at this stage. SOC 2 Type 2 becomes relevant when enterprise pilots materialize.

Healthcare SaaS, first enterprise hospital deal in pipeline: Start SOC 2 Type 2 if you do not already have it. Ask procurement at the target hospital which certification they require. Many accept SOC 2 + HIPAA self-attestation for initial contracts. Pin HITRUST i1 to a specific deal pattern where you lose on security posture.

Health IT vendor or MSP with established enterprise health customer base: HITRUST r2 is likely table stakes for your buyer segment. If competing vendors hold r2 and you do not, that is the signal. Factor 12 to 18 months of preparation if you are starting from SOC 2.

Digital health startup pursuing a large hospital or payer contract: Ask the buyer directly. If the MSA or security addendum requires r2, budget accordingly before signing a letter of intent. r2 cannot be rushed into a 90-day timeline without significant risk of failed assessments.

What the HITRUST assessor actually reviews

HITRUST assigns a maturity score (1-5) to each applicable control across five dimensions: Policy, Procedure, Implemented, Measured, Managed. A score of 3 (Implemented) across the control set is roughly the minimum to pass. Scoring below 3 on required controls results in a corrective action plan, which delays certification.

The common gaps that extend first-time HITRUST timelines:

• Written policies exist but are not versioned, dated, or tied to an approval workflow.
• Training records exist but cannot demonstrate every required staff member completed relevant modules.
• Risk assessments are present but were completed more than 12 months before the assessment date.
• BAAs are in place but the subcontractor inventory is incomplete.
• Encryption is implemented for data at rest and in transit but key management procedures are not documented.
• Vulnerability scans run on schedule but finding remediation is not tracked to closure.

Each of these is a documentation and process problem, not a technical one. Most can be addressed in three to six months if the technical controls are already in place from a SOC 2 program.

Recent developments

HITRUST CSF Version 11.4 was released in December 2024. The update incorporates threat intelligence from breach data analysis and refines control requirements across several domains. Organizations beginning a new assessment should confirm which framework version applies to their assessment window with their authorized assessor.

HITRUST AI Security Assessment: HITRUST introduced a dedicated AI security assessment in 2024, covering 51 controls aligned with ISO and NIST AI risk management guidance. This is separate from the e1/i1/r2 path and relevant for AI-enabled health applications that process PHI.

Mini-FAQ

Does HITRUST replace HIPAA? No. HITRUST certification demonstrates that your security program meets the controls in the CSF, which includes HIPAA Security Rule requirements. But HHS Office for Civil Rights enforces HIPAA independently. A HITRUST certificate is not a shield against OCR investigations. It is supporting evidence.

Is HITRUST mandatory for healthcare companies? No. HITRUST is voluntary. It becomes effectively required when a specific enterprise buyer's vendor risk process demands it. Most small medical practices and outpatient clinics do not require HITRUST from their software vendors.

Which is harder, HITRUST r2 or SOC 2 Type 2? HITRUST r2 is harder. It uses a five-point maturity scoring model that evaluates whether controls are documented, deployed, measured, and continuously improved. SOC 2 Type 2 asks whether a control existed and operated during the audit period. HITRUST i1 is generally estimated at roughly 1.5 times the work of a comparable SOC 2 Type 2 engagement.

Do I need both HIPAA compliance and HITRUST certification? If you pursue HITRUST, yes, you need both. HITRUST is built on HIPAA controls. An organization pursuing HITRUST that does not have a working HIPAA program will fail the assessment. The two are not alternatives.

What is the difference between HITRUST e1, i1, and r2? e1 (Essential) covers 44 core controls, valid for one year, designed for lower-risk vendors. i1 (Implemented) covers 182 control requirements, valid for one year, for organizations with a working security program that need enterprise credentialing. r2 (Risk-based) covers a tailored set of controls scoped by risk profile, valid for two years with an interim review, and is what enterprise health buyers typically require for high-risk vendor relationships.

What does MyCSF do? MyCSF is HITRUST's SaaS platform for managing the assessment lifecycle. It handles evidence collection, control tailoring, remediation tracking, and assessor collaboration. Organizations can also inherit validated controls from certified cloud service providers, which reduces the evidence burden for controls that upstream providers already carry.

Sources used

1. OCR — accessed 2026-05-12
2. 45 CFR Parts 160 and 164 — accessed 2026-05-12
3. 2024 inflation-adjusted figures published in the Federal Register — accessed 2026-05-12
4. HITRUST Common Security Framework (CSF) — accessed 2026-05-12
5. three certification tiers — accessed 2026-05-12
6. MyCSF platform — accessed 2026-05-12

Last reviewed: 2026-05-12. This article was prepared by the Security Compliance Guide Editorial Team. We use AI to draft initial summaries of publicly available cybersecurity compliance documentation, then verify every claim against primary sources before publication. We are not licensed auditors, attorneys, or compliance consultants. For binding decisions, consult a qualified professional. See our editorial standards for full sourcing rules.