HIPAA vs HITRUST: How a Federal Law Differs from a Certifiable Framework

HIPAA is a US federal law that healthcare organisations and their business associates must follow, while HITRUST is a private, certifiable control framework that many of them use to show how they meet HIPAA and other requirements. The two are often bundled together in contracts and vendor questionnaires, which leads to the common mistake of treating a HITRUST certificate as proof of HIPAA compliance, or treating HIPAA as something you can be certified against. This guide compares them side by side: legal status, scope, control depth, assessment, cost of effort, and how they fit together. It is for security and compliance leads at covered entities, health technology suppliers and business associates deciding what to build and what to buy. Status checked on 13 November 2026: the HIPAA Security Rule in force is the current rule, with a proposed update published by HHS on 27 December 2024 still in rulemaking, and the HITRUST CSF current version is v11.9.

Key takeaways

• One is mandatory, the other is chosen. HIPAA applies by law to covered entities and business associates; HITRUST applies only when an organisation, or its customer contract, chooses it.
• HIPAA says what to achieve, HITRUST says how to prove it. The Security Rule is risk-based and technology neutral; the HITRUST CSF turns that into prescriptive control requirements tested by an approved external assessor.
• A certificate is evidence, not a safe harbour. A HITRUST certification can help demonstrate Security Rule practices, but it does not replace your own risk analysis or remove HHS enforcement authority.
• Recognised security practices matter. Under Public Law 116-321, HHS must consider whether recognised security practices were in place for the previous 12 months when deciding fines, audit outcomes and remedies.
• Suppliers usually need both. A health technology vendor handling ePHI must comply with HIPAA as a business associate and is often asked for HITRUST by hospital and payer customers.

The short answer

If you create, receive, maintain or transmit electronic protected health information (ePHI) as a covered entity or business associate, HIPAA is not optional: you must meet the Privacy, Security and Breach Notification Rules. HITRUST is a way to organise and independently validate your security programme. Choose HITRUST when customers demand it, when you need one assessment to answer many frameworks at once, or when you want external assurance that your HIPAA programme works. Do not choose it as a substitute for the HIPAA risk analysis, policies and documentation the law requires. A small practice or a supplier with few customers may meet its obligations with a well-documented HIPAA programme aligned to NIST guidance and no HITRUST at all.

Side-by-side comparison

What HIPAA requires

The HIPAA Security Rule requires regulated entities to ensure the confidentiality, integrity and availability of all ePHI they create, receive, maintain or transmit, to protect against reasonably anticipated threats and impermissible uses or disclosures, and to ensure workforce compliance. HHS describes the rule as scalable and technology neutral: entities weigh their size and complexity, technical infrastructure, cost of measures, and the probability and criticality of risks. See the HIPAA Security Rule Guide for the full standard-by-standard walk through; this section covers only what matters for the comparison.

• Risk analysis (45 CFR 164.308(a)(1)(ii)(A), required): an accurate and thorough assessment of potential risks and vulnerabilities to the confidentiality, integrity and availability of ePHI. This is the foundation that no external certification replaces. See the HIPAA Security Risk Assessment Template.
• Safeguards: administrative (164.308), physical (164.310) and technical (164.312), including access control, audit controls, integrity, authentication and transmission security.
• Required vs addressable: addressable specifications are not optional. The entity implements them where reasonable and appropriate, or documents why not and adopts a reasonable alternative.
• Evaluation (164.308(a)(8)): a periodic technical and nontechnical evaluation, repeated after environmental or operational changes that affect ePHI security. This is the provision where an independent assessment such as HITRUST can provide evidence.
• Business associates: a covered entity may let a business associate handle ePHI only with satisfactory assurances, typically a business associate agreement that flows requirements to subcontractors and requires incident reporting. See the HIPAA Business Associate Agreements Guide.
• Documentation: kept for six years from the later of creation or last effective date.

Pending change: HHS, through OCR, issued a proposed rule to strengthen the Security Rule on 27 December 2024. HHS states that while it undertakes this rulemaking, the current Security Rule remains in effect. Check the HHS page before relying on any proposed provision. See the HHS HIPAA Security Rule Update (2025 NPRM) Guide.

What HITRUST provides

The HITRUST CSF is a control library for information security, privacy and risk management that harmonises more than 60 authoritative sources, including HIPAA, ISO/IEC 27001 and 27002, NIST SP 800-53 Rev. 5, PCI DSS and GDPR (HITRUST cites figures of both 60+ and 70+ on its own site). HITRUST updates requirements using threat intelligence and breach data through what it calls a Cyber Threat Adaptive engine. See the HITRUST CSF Guide for the framework in depth.

Assessments are performed by External Assessors that HITRUST approves. The three levels are designed so that work from an e1 or i1 can carry forward to a later i1 or r2, and HITRUST Insights Reports translate results into the language of specific standards, including HIPAA. Figures above are from HITRUST's own pages as checked in November 2026; confirm counts against the current CSF version.

How they work together

The link between the two is evidence. HIPAA sets the obligation and the enforcement; HITRUST can supply structured, independently tested proof that controls exist and operate. Three legal and practical connections matter.

1. Evaluation evidence: a HITRUST r2 with a HIPAA Insights Report is strong input to the 164.308(a)(8) evaluation, provided its scope covers the systems that hold ePHI.
2. Recognised security practices: Public Law 116-321, approved on 5 January 2021, added section 13412 to the HITECH Act. HHS must consider whether a covered entity or business associate adequately demonstrated recognised security practices in place for not less than the previous 12 months, which may mitigate fines, lead to early favourable termination of an audit, and mitigate remedies in resolution agreements. The law defines recognised security practices through NIST Act practices (such as the NIST Cybersecurity Framework), Cybersecurity Act of 2015 section 405(d) approaches, and other programmes recognised under statute, as determined by the entity. It does not name HITRUST. Whether a HITRUST-based programme qualifies depends on how it maps to those practices, so document the mapping. The section does not limit HHS authority to enforce the Security Rule.
3. NIST as common ground: NIST SP 800-66 Rev. 2 (February 2024) is a cybersecurity resource guide for implementing the Security Rule, and NIST's Cybersecurity and Privacy Reference Tool maps Security Rule standards to CSF subcategories and SP 800-53 Rev. 5 controls. HITRUST also harmonises SP 800-53, so a NIST mapping lets you show one control set against both.

Security trade-offs

• Flexibility vs consistency: HIPAA's flexibility lets a small practice right-size its controls but also lets a weak risk analysis justify weak controls. HITRUST's prescriptive requirements reduce that room, at the cost of effort that may not match a small organisation's risk.
• Point-in-time vs continuous: a certification reflects controls tested during the assessment. HIPAA obligations are continuous, so monitoring, re-evaluation after change, and incident handling must continue between assessments.
• Scope gaps: a HITRUST certificate covers the scope that was assessed. Systems, cloud accounts, integrations and non-human identities outside that scope can still hold ePHI and still fall under HIPAA.
• Identity controls: HIPAA technical safeguards require access control, unique user identification and authentication, but in technology-neutral terms. Service accounts, API keys and integration tokens that touch ePHI are within scope in practice and are often the weakest point. See the Machine Identity in Healthcare guide and the Healthcare Identity Security Guide.

The Change Healthcare breach shows why paper compliance is not enough: attackers used a compromised credential on a remote access portal that did not require multi-factor authentication, and the incident disrupted claims and pharmacy payments nationwide. The lesson for both frameworks is that every remote access path and every credential that can reach ePHI must be in scope and tested.

Decision guidance

How to implement both without duplication

1. Define the ePHI boundary. Inventory systems, data flows, cloud accounts, vendors and non-human identities that touch ePHI. This scope drives both the HIPAA risk analysis and the HITRUST assessment scope.
2. Complete the HIPAA risk analysis. Required regardless of HITRUST. Use it to set HITRUST risk factors if you pursue r2.
3. Build one control set. Map controls to HIPAA standards, NIST CSF 2.0 and, if pursued, HITRUST CSF requirements, using the NIST CPRT mappings as the bridge.
4. Run a readiness self-assessment. Treat it as a pilot: find gaps before an External Assessor tests controls.
5. Fix gaps, then assess. Prioritise access control, MFA on remote access, logging, backup and recovery, and vendor management.
6. Keep evidence for 12 months and longer. Recognised security practices must be shown for the previous 12 months, and HIPAA documentation for six years.
7. Re-evaluate after change. Major system, vendor or architecture changes trigger HIPAA evaluation and may need HITRUST scope updates.

Detection and measurement

• Risk analysis currency: date of last enterprise risk analysis and number of material changes since (target: reviewed at least annually and after each major change).
• Scope coverage: percentage of systems holding ePHI inside the assessed HITRUST scope, if certified.
• MFA coverage: percentage of remote access paths and privileged accounts with multi-factor authentication (target 100%).
• Business associate coverage: percentage of vendors handling ePHI with a signed BAA and current assurance evidence.
• Corrective actions: open assessment findings past due date.
• Audit log review: percentage of ePHI systems whose access logs feed monitoring and are reviewed.

Common mistakes

• "We are HIPAA certified." HIPAA has no certification scheme. Claim compliance with evidence, or name the actual assessment you hold.
• Using HITRUST instead of a risk analysis. The certification does not satisfy the required HIPAA risk analysis on its own.
• Narrow certification scope. Certifying one platform while ePHI also flows through analytics, support tools or integrations outside scope.
• Ignoring non-human access. Service accounts, API keys and integration tokens with access to ePHI left out of access reviews.
• Letting the programme lapse between assessments. Evidence gaps break the 12-month recognised security practices window.
• Assuming the proposed rule is in force. Plan for it, but comply with the current rule until HHS publishes a final rule with an effective date.

Framework mapping

Use the NIST CPRT mapping for authoritative detail; the table shows the main alignment only.

Decision checklist

• Are you a covered entity or business associate? If yes, HIPAA applies whatever else you choose.
• Is your HIPAA risk analysis current, thorough and documented?
• Do customers or contracts require HITRUST, and at which level (e1, i1, r2)?
• Would one HITRUST assessment replace several other questionnaires or audits?
• Does the proposed assessment scope cover every system, vendor and identity that touches ePHI?
• Can you evidence recognised security practices for the previous 12 months?
• Do you have budget and staff to maintain controls continuously, not only for the assessment?

Practitioner checklist

• Document the ePHI boundary, including cloud accounts, vendors and non-human identities.
• Complete and date the HIPAA risk analysis; repeat after material change.
• Map controls once to HIPAA, NIST CSF 2.0 and HITRUST CSF where pursued.
• Require MFA on every remote access path and privileged account.
• Keep BAAs current and collect assurance evidence from business associates.
• Choose the HITRUST level from customer demand and risk, not prestige.
• Retain evidence of practices for at least 12 months and documentation for six years.
• Track the HHS Security Rule rulemaking and update plans when a final rule is published.

Standards and references

• HHS: Summary of the HIPAA Security Rule
• HHS: HIPAA Security Rule Notice of Proposed Rulemaking
• 45 CFR 164.308: Administrative safeguards
• US Government Publishing Office: Public Law 116-321
• NIST: SP 800-66 Rev. 2, Implementing the HIPAA Security Rule
• HITRUST: HITRUST CSF
• HITRUST: Assessments and Certifications
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: HIPAA Security Rule Guide · HITRUST CSF Guide · Healthcare Cyber Regulation Map · HIPAA Breach Notification Rule Guide. This guide summarises HIPAA and HITRUST as of November 2026 and is not legal advice.