HIPAA Alongside SOC 2, ISO 27001 and PCI DSS
Running HIPAA next to another framework genuinely does cost less than running them separately, and the reasons are specific and explainable. What does not exist is a published number for either half of that claim: no authority publishes a control-overlap percentage, and no auditor publishes an engagement fee. This page gives you the mappings that are published, the mechanism that produces the saving, and the limits on how far it goes.
Start here: HIPAA is not a certification
Most cross-framework writing treats HIPAA as one certification among several that you can bundle into a single audit. It is not one. HHS says so in its own FAQ, and the wording matters because it changes what bundling can and cannot buy you:
“No, there is no standard or implementation specification that requires a covered entity to ‘certify’ compliance... It is important to note that HHS does not endorse or otherwise recognize private organizations' ‘certifications’ regarding the Security Rule, and such certifications do not absolve covered entities of their legal obligations under the Security Rule. Moreover, performance of a ‘certification’ by an external organization does not preclude HHS from subsequently finding a security violation.”
Source: HHS FAQ 2003. What the Security Rule does require is a periodic evaluation under 45 CFR 164.308(a)(8), which you may perform internally or have an external organization perform. So there is no HIPAA certificate, no accredited HIPAA auditor, and no HIPAA report to hand a customer. SOC 2 and ISO 27001 are assurance products with certificates and opinions; HIPAA is an obligation you map onto them.
The crosswalks that are actually published
The mapping work has been done, it is free, and almost nobody links to it. These are the primary artifacts.
HIPAA Security Rule Crosswalk to NIST Cybersecurity Framework
Published February 2016 by HHS OCR, developed with NIST and ONC. It maps, in its own words, “each administrative, physical and technical safeguard standard and implementation specification in the HIPAA Security Rule to a relevant NIST Cybersecurity Framework Subcategory.” Its Relevant Control Mappings column also carries ISO/IEC 27001:2013, NIST SP 800-53 Rev. 4, COBIT 5, ISA 62443 and CCS CSC. This is the closest thing to an official HIPAA-to-ISO 27001 mapping that exists.
Two things to know before you rely on it. It carries its own caveat that “the mappings between the Framework subcategories and the HIPAA Security Rule are intended to be an informative reference and do not imply or guarantee compliance with any laws or regulations,” and its footnote warns that “although all Security Rule administrative, physical, and technical safeguards map to at least one of the NIST Cybersecurity Framework Subcategories, other Security Rule standards, such as specific requirements for documentation and organization, do not.” And it has not been revised since 2016, so it maps CSF v1.0, ISO/IEC 27001:2013 and SP 800-53 Rev. 4, all three now superseded.
NIST SP 800-66 Revision 2, Appendix D
Published February 2024, this is the current NIST resource guide for implementing the Security Rule. Appendix D is the crosswalk to NIST SP 800-53 controls and CSF Subcategories, and NIST moved the mapping table out of the PDF and into the Cybersecurity and Privacy Reference Tool so that it can be kept up to date independently of the document.
Its footnote on methodology is the one that matters for anyone tempted to count rows: NIST states that its mapping to CSF Subcategories “was intentionally broad and includes mappings to Subcategories that both directly and indirectly align.” The mapping is deliberately over-inclusive. A percentage derived by counting its entries would overstate the real overlap, which is one concrete reason the number you see quoted elsewhere is not recoverable from the source it would need.
NIST SP 800-66 Rev. 2 · Cybersecurity and Privacy Reference Tool (free, exports to Excel and JSON)
Where the mapping runs out
HITRUST publishes an Authoritative Sources Cross Reference for the CSF, free of charge behind an email form, and markets the CSF as harmonising more than sixty frameworks. That is a count of sources it draws on, not a coverage figure. AICPA publishes mappings for the SOC suite, including SOC 2 Trust Services Criteria to HITRUST CSF and to NIST CSF, but they sit behind AICPA membership and the work product maps TSC to HITRUST rather than SOC 2 to HIPAA directly. The PCI Security Standards Council publishes no HIPAA mapping at all, which is unsurprising: PCI DSS is a contractual standard governing cardholder data and HIPAA is federal law governing ePHI, so neither body has an institutional reason to map to the other. Every PCI-to-HIPAA crosswalk you will find is a vendor artifact.
Why this page has no overlap percentage
Every body that did the mapping work published relationships and declined to publish a ratio. That is not an oversight, and the reasons are worth understanding before you accept a percentage from anywhere else.
- There is no common denominator. The Security Rule is built from standards and implementation specifications; ISO/IEC 27001:2022 Annex A has 93 controls; SOC 2 is built from criteria and points of focus. A percentage needs something to be a percentage of, and these do not count the same units.
- The mappings are many-to-many. One safeguard maps to several subcategories and one subcategory serves several safeguards, so counting entries double-counts rather than measuring coverage.
- Direction changes the answer. The share of HIPAA that SOC 2 covers is a different quantity from the share of SOC 2 that HIPAA covers. A bare percentage does not say which one it is.
- The available mapping is deliberately broad. NIST says its own alignment is intentionally over-inclusive, so deriving a figure from it inflates the result.
- HIPAA is risk-based and scalable. The Security Rule asks for safeguards that are reasonable and appropriate for your organisation, and it separates required from addressable specifications. Whether a given SOC 2 control satisfies a HIPAA requirement can depend on your own risk analysis. A control-count ratio cannot express that.
The practical version: the overlap is substantial and structural, which the published crosswalks demonstrate directly by mapping every administrative, physical and technical safeguard to something. Nobody has established what it is as a number, and any specific figure you are quoted is an estimate wearing a decimal point.
SOC 2 to HIPAA: what carries and what does not
SOC 2 is the most common pre-existing framework for business associates who then need HIPAA. Set aside the arithmetic and the split is qualitative and stable: the security control work largely carries, and the Privacy Rule work does not exist in SOC 2 at all.
Work that largely carries over
- Access control and user management
- Encryption at rest and in transit
- Audit logging and monitoring
- Change management procedures
- Incident response and management
- Vendor risk management
- Risk assessment methodology
- Contingency and business continuity planning
- Workforce screening
- Security awareness training
Work SOC 2 does not touch
- Privacy Rule policies and procedures
- Notice of Privacy Practices (covered entities)
- Patient access rights under 164.524
- The minimum necessary standard
- Business Associate Agreement management
- Breach notification under 164.404 and 164.410
- PHI-specific handling procedures
- HIPAA-specific workforce training
The right-hand column is the part that surprises business associates who arrive with a clean SOC 2 Type II report. None of it is security work, none of it was in scope for the SOC 2, and the Privacy Rule has no equivalent anywhere in ISO 27001 either. It is also, notably, the column that OCR enforcement most often lands on: the recurring findings in published resolution agreements are a missing or inadequate risk analysis and gaps in access management, not exotic technical failures.
How bundling actually saves money
The saving is real and you can reason about it without a price. It lives in testing and coordination labour, not in the frameworks merging.
- Test once, satisfy many. An access-control or encryption control tested once produces evidence that maps to several frameworks. The assessor does the test once rather than repeating it per report.
- One evidence-collection pass. User-access reviews, change tickets and log samples get pulled once for several report tracks. Sequential audits request the same artifacts months apart, and your staff assemble them again each time.
- One fieldwork mobilisation. Planning, scoping, walkthroughs, kickoff, sampling and the closing meeting are largely fixed costs. Incurring them once instead of several times is where much of the difference sits.
- Aligned observation windows. Running a SOC 2 Type II period concurrently with an ISO surveillance cycle avoids maintaining two separate evidence regimes across the calendar.
- Common readiness work. The gap assessment, policy authoring, risk assessment and training are done once rather than re-scoped per framework.
- Scope overlap. Same systems, same people, same data flows, described once and interviewed once.
- Your own coordination cost. Usually the most underestimated line. Staff time spent answering the same questions for a second and third assessor is frequently the largest real saving, and it never appears on an assessor invoice.
The limits are equally concrete, and they cap how much can collapse:
- A SOC 2 Type II needs its observation period. Typically three to twelve months of operating effectiveness. Bundling does not compress the calendar.
- ISO 27001 runs on its own cadence. A two-stage initial certification, then annual surveillance with recertification at year three. That schedule is set by the scheme and will not align to your SOC 2 window for free.
- The hats are different. ISO 27001 certification must be issued by a certification body accredited under ISO/IEC 17021-1; a SOC 2 must be performed by a licensed CPA firm. Independence rules can prevent one organisation doing everything, so some bundles are two engagements sold together rather than one engagement.
- The deliverables do not merge. SOC 2 produces an attestation opinion, ISO produces a certificate, and HIPAA produces neither. They are not interchangeable.
- The remainder is still work. Whatever does not overlap still needs discrete effort, so the saving is never total.
What any of this costs
No assessment firm publishes an engagement fee. Schellman's own page on the subject sets out the method and no figure, describing how it combines historical project statistics with an initial scoping discussion “to provide outcome-based fixed-fee arrangements confidently and consistently.” That is the norm across the industry: this work is quoted per engagement against your scope, your systems and your headcount, and there is no rate card to compare. Ranges attributed to named firms elsewhere are estimates that the firms themselves did not publish.
HITRUST is the one place published figures exist, and it is instructive about exactly where they stop. HITRUST's own pricing guidance states that MyCSF subscriptions “typically cost from $18,100” and that a readiness assessment report “begins at $3,625” (hitrustalliance.net, checked July 2026). Both are floors. Both are HITRUST's own platform and report fees, and neither is the cost of an assessment. On the part that usually dominates the budget, HITRUST states that “each assessor determines their own pricing” and that HITRUST “is not involved in the assessor fees.” The largest component of a HITRUST engagement has no published number, by the scheme owner's own account.
This is why you will not find a combined-audit price table on this page. There is no published fee to compare a bundle against, so a bundled figure and a separate figure would both be invented, and a percentage saving derived from the two would be arithmetic performed on nothing. The mechanism above is what to take to your own quotes: ask an assessor to price the frameworks sequentially and together, and the difference will be their number for your scope, which is the only number in this area that means anything.
ISO 27001 to HIPAA
ISO 27001 is the framework with the most direct published relationship to HIPAA, because the 2016 OCR crosswalk carries ISO/IEC 27001:2013 references in its mapping column alongside the CSF subcategories. The Information Security Management System maps onto the Security Rule's administrative, physical and technical safeguards, and an organisation with a mature ISMS has done a large part of the Security Rule's administrative work already. The gaps are the ones no international security standard addresses: the Privacy Rule in its entirety, US healthcare-specific terminology and obligations, the BAA requirement, and breach notification on the HIPAA timetable. Note the version drift when you use the crosswalk: it maps ISO/IEC 27001:2013, and Annex A was restructured in the 2022 revision, so the control identifiers will not line up directly with a current certificate.
PCI DSS to HIPAA
A practice that takes patient payments and holds ePHI is in scope for both, but they are not two versions of one obligation: PCI DSS is a contractual standard imposed by the card brands over cardholder data, and HIPAA is federal law over PHI. They govern different data in different systems, and the PCI Security Standards Council publishes no HIPAA mapping. Where the two do meet is in the shared machinery of encryption, access control, audit logging and network security, and PCI DSS is more prescriptive than HIPAA in several places, notably network segmentation, quarterly vulnerability scanning and annual penetration testing. That prescriptiveness is worth noting for planning: the 2026 Security Rule proposals would move HIPAA toward explicit cadences of the kind PCI DSS has always specified, so an organisation already running a PCI programme has the operational habits, if not the scope, for what is proposed.