HIPAA, HITRUST, and SOC 2 Control Mapping: How to Stop Doing the Same Work Three Times

If your organization handles protected health information, there is a good chance you are being asked about all three at once. A health-system customer wants a HITRUST certification. A payer’s procurement team wants a SOC 2 Type 2 report. Underneath both, HIPAA has been the law the whole time. It is tempting to treat these as three separate projects with three separate budgets and three separate binders, which is exactly how compliance teams end up doing the same work three times. In practice, the three frameworks overlap heavily, because they are all describing variations on the same set of security controls. This guide walks through how HIPAA, HITRUST, and SOC 2 map to one another, where they genuinely diverge, and how to build one control program that satisfies all three.

What each framework is

The single most common source of confusion is that these three things are not the same kind of thing at all. Getting that straight first makes the mapping much easier.

• HIPAA is a law. The HIPAA Security Rule (45 CFR Part 164, Subpart C) sets required and addressable standards across administrative safeguards (§164.308), physical safeguards (§164.310), technical safeguards (§164.312), organizational requirements (§164.314), and policies, procedures, and documentation (§164.316). There is no HIPAA certificate. Nobody “passes” HIPAA. You either comply or you do not, and OCR finds out during an investigation or audit.
• HITRUST is a certifiable framework. The HITRUST CSF is a prescriptive control framework that harmonizes HIPAA, NIST, ISO, and dozens of other authoritative sources into a single set of requirement statements, assessed by an authorized external assessor. The current release is CSF v11.8.0, published in May 2026, which continued consolidating overlapping requirement statements and added mappings including NIST SP 800-137, ISO/IEC 29100:2024, and the OWASP Top 10 for LLM Applications. HITRUST offers tiered assessments (e1, i1, and r2) at increasing levels of rigor.
• SOC 2 is an attestation report. A SOC 2 engagement is performed by a CPA firm against the AICPA’s Trust Services Criteria, Security (always required), plus optionally Availability, Processing Integrity, Confidentiality, and Privacy. A Type 1 report tests whether controls are designed appropriately at a point in time; a Type 2 report tests whether they operated effectively over a period, typically six to twelve months.

So: one is a legal obligation, one is a certification, and one is an auditor’s opinion. Yet all three are asking your organization to demonstrate essentially the same underlying capabilities.

Where the controls overlap

Once you look past the vocabulary, the same control families show up in all three. A workforce access-review process is a HIPAA administrative safeguard, a HITRUST access-control requirement, and a SOC 2 logical-access criterion, one process, three labels. The high-overlap areas are consistently:

• Access control and identity. Unique user IDs, role-based access, least privilege, periodic access reviews, and termination workflows. HIPAA §164.308(a)(3), (4) and §164.312(a); SOC 2 logical-access criteria; HITRUST access-control domains.
• Risk analysis and risk management. HIPAA requires an accurate and thorough risk analysis and a risk-management plan. HITRUST and SOC 2 both expect a documented, repeatable risk-assessment process feeding remediation. This is the true keystone control, see our overview of the HIPAA Security Risk Analysis.
• Audit logging and monitoring. HIPAA §164.312(b) audit controls; SOC 2 monitoring criteria; HITRUST logging requirements.
• Encryption and transmission security. HIPAA treats encryption as addressable; HITRUST and SOC 2 auditors will effectively expect it. In practice, “addressable” has never meant optional, it means justify and document if you do something else.
• Incident response and breach handling. All three require a documented, tested process. HIPAA layers on the Breach Notification Rule’s specific notification duties.
• Vendor and third-party risk. HIPAA requires business associate agreements; HITRUST and SOC 2 require supplier due diligence and ongoing monitoring. This is where most healthcare programs are thinnest, see our guide to third-party risk management in healthcare and why a signed BAA is not a vendor risk assessment.
• Workforce training and awareness. Required by HIPAA, expected by both others.
• Contingency planning. Backups, disaster recovery, and testing.

The practical implication is significant: the evidence you produce for one framework is very often the same evidence, unchanged, for the other two. One access-review export. One risk-analysis report. One incident-response tabletop record. What changes is the label on the folder and the level of proof the assessor expects.

Where they genuinely diverge, and why it matters

Mapping is powerful, but pretending the frameworks are identical is how teams get burned in an audit. The real gaps:

• SOC 2 does not make you HIPAA compliant. This is the single most expensive misunderstanding in healthcare procurement. A SOC 2 Type 2 report says an auditor tested the controls you selected against the Trust Services Criteria. It says nothing about BAAs, the minimum-necessary standard, patient rights of access, breach notification timelines, or the specific documentation HIPAA demands. A vendor can hold a clean SOC 2 and still be out of compliance with HIPAA.
• HIPAA has patient-facing obligations no security framework covers. The Privacy Rule, notices of privacy practices, right of access, accounting of disclosures, has no SOC 2 or HITRUST equivalent unless you specifically scope the Privacy criteria in.
• HITRUST is prescriptive; HIPAA is not. HIPAA tells you to implement access controls. HITRUST tells you what “good” looks like at your organization’s size and risk tier, and then scores you on it. That prescriptiveness is why HITRUST is harder, and why it is worth more to a health-system buyer.
• Scope boundaries differ. SOC 2 scopes to a system or service. HIPAA scopes to all PHI your organization creates, receives, maintains, or transmits, including the laptop in the billing office that is nowhere near your product.

How to build one program instead of three

The mapping approach that works in practice is to treat HIPAA as the floor, pick the most demanding framework you are being asked for as the ceiling, and build a single control set that reaches the ceiling.

1. Start with the HIPAA Security Risk Analysis. It is legally required regardless, and it produces the asset inventory, threat picture, and gap list that every other framework will ask for anyway. Doing HITRUST or SOC 2 first, and HIPAA second, is doing it backwards.
2. Build one control register, not three. Each control gets one owner, one description, one piece of evidence, and a mapping column listing every framework citation it satisfies (HIPAA §164.308(a)(1)(ii)(A) / HITRUST requirement / SOC 2 CC-series criterion).
3. Collect evidence once. If an access review is run quarterly and exported to a consistent location, it serves the HIPAA documentation requirement, the HITRUST assessor, and the SOC 2 auditor without a second collection cycle.
4. Close the vendor gap deliberately. This is the most common cross-framework failure. A BAA inventory alone will not survive a HITRUST assessment or a serious SOC 2 vendor-management review; you need risk-tiered assessments and ongoing monitoring behind it.
5. Keep it current. HIPAA compliance is not an annual event, and neither is a Type 2 report, which tests operation over time. A control that only exists in the two weeks before an audit will fail a Type 2 test.

Medcurity was built around exactly this problem: a healthcare-native platform where the Security Risk Analysis, policies, workforce training, and vendor risk assessments live in one place, so the evidence you generate for HIPAA is the same evidence you hand an assessor. Pricing starts at $499/year for small practices and scales with organization size, so you fund one program instead of three.

Talk to us about building a single control program that maps across HIPAA, HITRUST, and SOC 2 →

Frequently asked questions

Does a SOC 2 report make us HIPAA compliant?

No. A SOC 2 report is an auditor’s opinion on controls you selected, measured against the AICPA Trust Services Criteria. It does not cover HIPAA-specific obligations such as business associate agreements, the minimum-necessary standard, patient right of access, breach notification, or the Security Rule’s required risk analysis. Many organizations hold a clean SOC 2 and still have HIPAA gaps.

Is HITRUST certification required for HIPAA?

No. HIPAA is a law with no certification scheme, there is no such thing as being “HIPAA certified” by the government. HITRUST is a voluntary framework and certification that many health systems and payers require of their vendors because it provides third-party assurance that HIPAA-aligned controls are in place.

Which framework should we pursue first?

Start with HIPAA, because it is legally required and its Security Risk Analysis produces the inventory, threat assessment, and gap list that both HITRUST and SOC 2 will ask for. Then pursue whichever certification your customers are demanding. Building HIPAA compliance last, after a SOC 2 or HITRUST push, almost always means redoing work.

How much of the evidence is genuinely reusable across the three?

A large majority of the core security evidence is reusable: access reviews, risk analysis, audit logs, encryption configuration, incident-response documentation, training records, vendor due diligence, and contingency-plan testing all satisfy requirements in all three. What does not carry over are HIPAA’s patient-facing Privacy Rule obligations and the framework-specific scoping and assessor documentation each certification requires.