Healthcare post-SOC 2 compliance now starts with HIPAA

At a glance

What this is: This is a healthcare sequencing analysis showing that SOC 2 is not the final step after certification and that HIPAA, then selectively HITRUST, usually defines the next compliance move.

Why it matters: It matters because IAM, access control, evidence collection, and audit readiness must be aligned to PHI handling and not just generic assurance, especially when healthcare buyers expect HIPAA operationalisation before HITRUST scope decisions.

By the numbers:

• HITRUST e1 covers roughly 44 controls and runs $35,000 to $50,000.
• HITRUST i1 covers around 182 controls and runs $70,000 to $120,000.
• HITRUST r2 scores 200-plus controls against maturity and can run $100,000 to $500,000 or more.

👉 Read Drata's healthcare sequencing analysis for SOC 2, HIPAA, and HITRUST

Context

Healthcare compliance after SOC 2 is a sequencing problem, not a brand preference exercise. Once an organisation creates, receives, maintains, or transmits PHI, HIPAA is not optional, and the first question becomes whether existing security controls actually satisfy the Security Rule for ePHI.

That matters for identity and access governance because healthcare evidence usually spans human access, service accounts, third-party workflows, and audit trails. Teams that already have SOC 2 evidence still need to map it to HIPAA obligations and then decide whether HITRUST is required by a buyer contract or by growth strategy.

The post-SOC 2 starting position is often optimistic but incomplete. Many teams assume one assurance framework can substitute for another, when the real issue is whether the control environment is already operational for PHI handling.

Key questions

Q: How should healthcare teams sequence SOC 2, HIPAA, and HITRUST after certification?

A: Start with PHI flow mapping, then make HIPAA operational, then choose HITRUST only when a buyer contract or market requirement justifies it. SOC 2 can support the evidence base, but it does not replace HIPAA obligations or determine the correct HITRUST tier. Sequencing matters because scope errors create rework, cost, and delayed deals.

Q: Why do HIPAA requirements usually come before HITRUST for healthcare vendors?

A: Because HIPAA is a legal obligation the moment PHI is created, received, maintained, or transmitted. HITRUST is an assurance layer that many buyers request, but HIPAA defines the baseline control duties. If HIPAA is not operational first, a team can certify against a weak or incomplete control environment.

Q: What do healthcare teams get wrong about post-SOC 2 compliance planning?

A: They often treat SOC 2 as if it were the final assurance state and then add HITRUST without first validating whether the organisation is actually handling PHI correctly. The better approach is to map existing controls to HIPAA, close the real gaps, and only then scope HITRUST to the buyer's requirement.

Q: Who is accountable if a healthcare organisation chooses the wrong HITRUST tier?

A: Accountability sits with the team that approved scope, usually across security, compliance, and procurement. The wrong tier is not just a certification mistake. It can create budget overruns, timeline slippage, and a mismatch between what the buyer asked for and what the organisation prepared to prove.

Technical breakdown

How HIPAA maps onto SOC 2 controls

SOC 2 and HIPAA overlap on several security themes, especially access control, encryption, monitoring, and incident response. The difference is that HIPAA is written around PHI use and disclosure, so a team must prove that controls work for ePHI in specific operational flows, not just that a control exists in policy. The Privacy Rule governs permitted use and disclosure, the Security Rule governs safeguards, and the Breach Notification Rule governs reporting after an incident. That means evidence has to show both technical control operation and the business process around it.

Practical implication: map each SOC 2 safeguard to HIPAA security requirements and document where PHI-specific workflows still need separate controls.

Why the proposed Security Rule changes matter for identity and encryption

The proposed rewrite would remove the 'addressable' category, which currently lets organisations document alternatives for some safeguards. If finalised as proposed, controls such as multi-factor authentication, encryption of ePHI at rest and in transit, and tighter breach reporting would move from flexible design choices to baseline expectations. For identity teams, that raises the bar on authentication strength, credential protection, and the evidence required to show access is continuously governed. The direction of travel is clearer than the final text: regulators are pushing toward stricter, less negotiable control requirements.

Practical implication: treat MFA, encryption, and breach-response evidence as mandatory design assumptions in healthcare programmes now.

How HITRUST tiers change the operational burden

HITRUST is not a single threshold. e1 is the smallest assessment, i1 is the mid-tier option most often requested in health system contracts, and r2 is the full risk-based assessment that measures maturity rather than simple implementation. The wrong tier creates avoidable cost and delay because scoping drives evidence volume, control depth, and certification length. In practice, the control question is not whether HITRUST is 'good enough', but which tier a buyer contract actually requires and whether the current control environment can support that scope without rework.

Practical implication: confirm the required HITRUST tier before scoping remediation, evidence collection, or external assessment work.

NHI Mgmt Group analysis

HIPAA is the real post-SOC 2 baseline in healthcare. SOC 2 may satisfy buyer diligence, but it does not decide whether PHI handling is legally defensible. Once PHI enters the environment, the organisation needs controls mapped to HIPAA's Privacy, Security, and Breach Notification Rules, which means assurance must be tied to regulated data flows rather than generic trust language. The practitioner conclusion is simple: treat HIPAA operationalisation as the next control milestone, not as paperwork.

The proposed Security Rule rewrite would turn flexibility into a stricter identity and encryption mandate. Removing the 'addressable' category would narrow the room for compensating controls and make authentication strength and encryption posture more testable. That has direct implications for IAM programmes because healthcare teams will need stronger evidence around access enforcement, secret handling, and incident reporting timelines. The practitioner conclusion is that programme design should assume the stricter draft until the final rule lands.

HITRUST scoping failures are usually governance failures, not assessment failures. Teams often choose the wrong tier because contract language was never parsed carefully enough, which turns a compliance project into an avoidable budget and timeline problem. This is a control-planning issue, not just a certification issue. The practitioner conclusion is that procurement, security, and compliance must agree on scope before any remediation work begins.

Control mapping beats control rebuilding in post-SOC 2 healthcare programmes. The post makes clear that much of SOC 2 already overlaps with HIPAA, so the best path is to reuse evidence, close true gaps, and reserve HITRUST for buyer-driven demand. That approach reduces corrective action risk and keeps the programme focused on PHI handling rather than duplicate assurance. The practitioner conclusion is to build one evidence spine that can support multiple frameworks without recreating the security programme.

Healthcare creates a verification trust gap when compliance is treated as a market choice. In regulated workflows, identity proof, access governance, and evidence collection all become part of the compliance boundary. The healthcare-specific challenge is not just whether a user or system can authenticate, but whether the organisation can prove that access to PHI is lawful, monitored, and lifecycle-managed. The practitioner conclusion is to align identity controls with regulated data handling, not with certification optics.

What this signals

Healthcare programmes should expect identity governance to become more audit-intensive as HIPAA tightening continues and buyers push deeper into assurance models. The practical shift is toward evidence that can be reused across frameworks, especially where service accounts, third-party access, and workflow automation touch PHI. For teams building that spine, the Lifecycle Processes for Managing NHIs section is the most relevant reference point.

PHI assurance drift: when a company keeps layering frameworks without first operationalising HIPAA, the programme begins to drift away from actual regulated-data risk. That creates duplicated evidence collection and weak control ownership. Teams should anchor the roadmap in access governance, breach readiness, and the ability to prove who can touch PHI, when, and why.

The tighter the healthcare compliance environment becomes, the more valuable it is to reuse a single evidence model across SOC 2, HIPAA, and HITRUST. That means mapping identity controls to regulated workflows, not just storing screenshots for audit season. Where NHI and workload access is part of those flows, the governance standard should move closer to lifecycle-managed access and away from static certifications.

For practitioners

• Map PHI flows before selecting the next framework Inventory every place PHI enters, moves through, or leaves the environment, including subprocessors and any workflow touching a covered entity's data. Use that map to decide which controls belong to HIPAA baseline evidence and which belong to buyer-driven HITRUST scope.
• Operationalise HIPAA before buying more assurance Close the Security Rule gaps that SOC 2 does not fully cover, especially PHI-specific administrative controls, breach procedures, and access evidence. Reuse existing SOC 2 artefacts where they fit, but do not assume they are sufficient on their own.
• Confirm the required HITRUST tier in contract language Read the buyer requirement carefully and verify whether it calls for e1, i1, or r2 before scoping the assessment. The tier choice determines evidence depth, assessment cost, and the time required to reach certification.
• Prepare for stricter MFA and encryption expectations Assume the proposed Security Rule direction will persist and build identity and data protection evidence around stronger authentication, ePHI encryption, and tighter reporting timelines. That reduces the risk of a second remediation cycle after the final rule is published.

Key takeaways

• SOC 2 is useful evidence in healthcare, but HIPAA still defines the legal baseline for PHI handling.
• The proposed HIPAA Security Rule would reduce flexibility and make stronger authentication and encryption expectations harder to avoid.
• HITRUST should follow a clear contract-driven scope decision, because the wrong tier adds cost without solving the underlying governance gap.

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.
• HIPAA Security Rule: The HIPAA Security Rule is the set of administrative, physical, and technical safeguards that protect electronic protected health information. It is not a product checklist. It requires organisations to prove that controls are designed, implemented, and operated in ways that reduce improper access and disclosure risk.
• HITRUST: HITRUST is a certifiable assurance framework that combines requirements from healthcare and security standards into a single control structure. It is used to demonstrate a stronger compliance posture to buyers, but the right tier and scope depend on contract language and the organisation's operational maturity.
• Business Associate: A business associate is any external organisation that handles PHI on behalf of a covered entity. The term matters because liability and security obligations extend beyond the primary healthcare provider, making third-party access governance, contract terms, and technical controls part of the same compliance chain.

What's in the full article

Drata's full post covers the operational detail this analysis intentionally leaves for the source:

• A step-by-step breakdown of how to map existing SOC 2 evidence to HIPAA Security Rule safeguards.
• A cost and scope comparison of HITRUST e1, i1, and r2 for different healthcare sales motions.
• A practical sequencing model for deciding when HIPAA comes first and when HITRUST becomes necessary.
• The specific control and documentation gaps healthcare teams should expect to close before an external assessment.

👉 Drata's full post covers the sequencing examples, scope mistakes, and remediation timing in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It gives security and identity practitioners a structured way to connect access governance with broader assurance programmes.