Healthcare post-SOC 2 compliance now starts with HIPAA

At a glance

What this is: This analysis argues that SOC 2 is only the start for healthcare organisations handling PHI, because HIPAA becomes mandatory and the right HITRUST tier depends on buyer and contract requirements.

Why it matters: For IAM, PAM, NHI, and broader security programmes, the article matters because healthcare compliance sequencing now affects access controls, evidence collection, and whether controls are mapped to legal obligations or optional assurance.

By the numbers:

• HITRUST e1 covers roughly 44 controls, runs $35,000 to $50,000, and carries a one-year validity.
• HITRUST i1 covers around 182 controls, runs $70,000 to $120,000, and is the tier most health plan and hospital system contracts actually mean when they say "HITRUST required."
• HITRUST r2 scores 200-plus controls against maturity, runs $100,000 to $500,000 or more, and carries a two-year certification with a required interim assessment at year one.
• The federal target for finalizing the proposed HIPAA Security Rule moved to July 2027.

Context

Healthcare compliance after SOC 2 is not a generic assurance question. Once a team creates, receives, maintains, or transmits protected health information, HIPAA becomes a legal obligation and the control discussion changes from buyer preference to regulatory duty.

That matters because SOC 2 overlaps with HIPAA security requirements but does not cover the full compliance picture. In healthcare, the practical gap is usually not whether a control exists, but whether the organisation has mapped evidence, business associate obligations, and the right assurance tier to the actual regulatory and contracting context.

Key questions

Q: What breaks when a healthcare team treats SOC 2 as the end state after handling PHI?

A: The team can end up with strong assurance evidence but weak legal alignment. SOC 2 does not replace HIPAA, so PHI workflows still need privacy, security, and breach notification governance. The failure mode is assuming buyer assurance equals regulatory compliance, which leaves administrative controls and PHI-specific obligations under-mapped.

Q: How should healthcare teams choose between HIPAA and HITRUST for access control?

A: They should not treat them as substitutes. HIPAA sets the legal requirements for protecting PHI, while HITRUST provides a prescriptive framework that helps organisations implement and evidence those requirements. The practical decision is to use HIPAA as the obligation and HITRUST, or an equivalent control model, as the operating structure for access governance.

Q: What do security teams get wrong about HITRUST tiers?

A: They often assume the most demanding tier is automatically the right one. In practice, e1, i1, and r2 solve different contracting problems, and the wrong choice can waste months and hundreds of thousands of dollars. The correct question is what the buyer contract actually requires, not which tier sounds strongest.

Q: Which controls should healthcare teams prepare for in the proposed HIPAA Security Rule?

A: They should expect stronger baseline expectations around multifactor authentication, encryption of ePHI at rest and in transit, and tighter breach reporting discipline. The practical test is whether those controls are already operational and evidenced, not whether they are simply planned for a future compliance cycle.

Technical breakdown

Why HIPAA becomes the baseline once PHI is in scope

HIPAA is not a certification tier chosen at the end of a sales cycle. It is the legal framework that governs PHI handling, and it applies when data is created, received, maintained, or transmitted in a covered workflow. The Privacy Rule governs permitted use and disclosure, the Security Rule governs administrative, physical, and technical safeguards for ePHI, and the Breach Notification Rule governs reporting after an incident. SOC 2 can support parts of the Security Rule, but it does not replace HIPAA's legal obligations or the administrative controls around notices and business associate agreements.

Practical implication: Map every PHI touchpoint to HIPAA obligations before using SOC 2 evidence as a readiness shortcut.

How HITRUST converts healthcare assurance into tiered control scope

HITRUST is a certifiable framework that packages requirements from HIPAA, NIST, ISO 27001, and other sources into defined assessment tiers. The key technical point is that each tier changes the control depth and the evidence burden. e1 is narrow and fast, i1 is broader and is commonly requested in health system contracting, and r2 adds maturity scoring rather than simple implementation checks. In practice, the tier matters more than the badge. A misread contract can turn a manageable assessment into a costly overbuild or, worse, a missed requirement.

Practical implication: Confirm the exact HITRUST tier in buyer language before scoping controls, evidence, or timelines.

What the proposed HIPAA Security Rule change means for control design

The proposed rewrite would remove the current distinction between required and addressable safeguards, pushing more controls into mandatory status. That includes stronger expectations for multifactor authentication, encryption of ePHI at rest and in transit, and tighter breach reporting timelines. For security architecture, this shifts HIPAA from a framework where some compensating controls can be justified to one where baseline implementation becomes more uniform. Teams that wait for final rule publication risk a second remediation cycle when draft expectations become enforceable requirements.

Practical implication: Design HIPAA control uplift against the draft rule now so encryption, MFA, and reporting changes are not reworked later.

NHI Mgmt Group analysis

HIPAA, not SOC 2, defines the real compliance floor for healthcare workflows handling PHI. SOC 2 can validate security discipline, but it does not itself create the legal obligations that arise once PHI enters scope. That distinction matters because governance teams often confuse buyer assurance with regulatory compliance. The correct model is to treat SOC 2 as supporting evidence, not as the compliance endpoint.

Healthcare assurance breaks when teams choose HITRUST before they have operational HIPAA controls. That sequencing mistake turns assessment into a paper exercise and often exposes gaps in business associate management, notice handling, and evidence quality. The practical lesson is that assurance tier selection must follow control maturity, not precede it.

Proposed HIPAA changes signal a move away from discretionary safeguards toward explicit baseline controls. When addressable categories disappear, the burden shifts from explaining why a control was omitted to proving that it exists and operates. For security and identity programmes, that means MFA, encryption, and reporting discipline stop being optional design choices and become architecture assumptions.

Healthcare compliance debt is often an evidence problem before it is a technology problem. Teams usually have some of the needed technical controls already, but they lack mapped evidence across PHI flows, subprocessors, and business associate agreements. That is the hidden governance gap: the control may exist, but the audit trail does not show it cleanly enough to satisfy healthcare buyers or regulators.

HITRUST tier selection is a governance decision, not a prestige decision. The article makes clear that many teams over-scope into r2 when i1 would satisfy the buyer, or under-scope when the contract language actually demands deeper assurance. Practitioners should treat the tier as a contract interpretation problem first and a security project second.

From our research library:

• 60% of healthcare organisations do not assess a vendor's security before signing a contract that grants access to protected health information, according to Ponemon Institute's 2023 Third-Party Risk in Healthcare report.

What this signals

Healthcare compliance sequencing is now a control-mapping problem, not a document-collection problem. Teams that already operate access control, logging, and incident response still need to prove how those controls map to PHI obligations and buyer requirements. The strongest programmes will treat HIPAA as the governing baseline and use HITRUST only when contract scope makes it necessary.

Control maturity matters more than assurance volume. A team that rushes into a deeper HITRUST tier before it has stable PHI handling, business associate oversight, and evidence discipline is buying complexity ahead of readiness. The better signal is whether the organisation can show the same control working across PHI flows, audits, and partner reviews.

Healthcare organisations should expect more explicit requirements around encryption and multifactor authentication as the proposed Security Rule direction hardens. That means identity and access teams need to treat PHI systems as a priority zone for stronger authentication and key management discipline, not a later-phase cleanup item.

For practitioners

• Map PHI flows end to end Inventory every workflow where PHI enters, moves through, or leaves the environment, including subprocessors and partner integrations.
• Treat HIPAA as the baseline control set Map existing SOC 2 evidence to HIPAA Privacy, Security, and Breach Notification obligations, then document the missing administrative safeguards.
• Confirm the exact HITRUST tier in contract language Validate whether the buyer requires e1, i1, or r2 before scoping assessment work or estimating cost and timing.
• Update control design for the proposed Security Rule Build encryption, multifactor authentication, and breach reporting expectations into the roadmap now so final rule changes do not force a second remediation cycle.
• Monitor business associate agreements continuously Treat BAA obligations as an active control that needs review, ownership, and evidence, not as static paperwork filed once per deal.

Key takeaways

• SOC 2 can support healthcare assurance, but it does not displace HIPAA once PHI is in scope.
• The right HITRUST tier depends on buyer and contract language, not on a default preference for the strongest assessment.
• The proposed HIPAA Security Rule points toward mandatory baseline controls that security teams should be operationalising now.

Key terms

• Protected Health Information: Protected Health Information is any health-related data that can identify a person and is covered by HIPAA protections. In practice, PHI can flow through applications, integrations, service accounts, and cloud systems, which is why identity governance matters as much as data governance.
• Business Associate Agreement (BAA): A BAA is a contract that governs how a third party may handle PHI on behalf of a covered entity. It is not just paperwork. It is an enforceable control that defines permitted use, safeguards, and accountability across vendor relationships.
• HITRUST Assessment Tier: A HITRUST assessment tier defines the depth and maturity of controls a healthcare organisation must demonstrate. Different tiers create different evidence and assurance burdens, so the right choice depends on the buyer's contractual requirement and the organisation's current control maturity.
• Addressable Safeguard: An addressable safeguard is a HIPAA control that must be considered and addressed, but not always implemented exactly as written. The organisation can use an equivalent alternative if it is supported by a risk analysis and documented rationale. Addressable does not mean optional or ignorable.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It suits practitioners who need to connect access governance, secrets handling, and lifecycle control to broader security programmes.