When a vendor says it is HIPAA compliant or SOC 2 compliant, what has actually been done?
One is a federal regulation you are legally bound by. The other is an examination report an accountant writes about controls you designed yourself. They are not two versions of the same thing — and the difference decides what a vendor’s claim is actually worth to you.
No such number exists. Controls are defined by the organization, not the AICPA.
01The big picture
Two different kinds of thing that happen to overlap
Before comparing requirements, get the categories right. Most confusion about vendor claims comes from treating a law and an audit report as though they were competing checklists.
Federal regulation
HIPAA
Health Insurance Portability and Accountability Act — Security Rule
The question it answers
“How are you protecting regulated healthcare information?”
Primary concern. Protecting protected health information, and specifically electronic PHI (ePHI).
Legal status
Design philosophy
Applies to
Third-party validation
Scales with
Who issues it
Nobody. HHS issues no certificate and endorses no private one.
What it proves
Nothing is 'proven' by a document. Compliance is a continuing state, assessed against your own environment, risk analysis, and PHI flows.
Independent assurance examination
SOC 2
System and Organization Controls 2
The question it answers
“Can customers trust the way you operate and protect their information and systems?”
Primary concern. How a service organization protects customer information and runs its systems, against the commitments it has made.
Legal status
Design philosophy
Applies to
Third-party validation
Scales with
Who issues it
A CPA firm issues a report — an opinion, not a certificate.
What it proves
That an independent practitioner examined controls the ORGANIZATION defined, against criteria the AICPA defined, and formed an opinion about them.
These are not two competing standards. They are different kinds of thing.
HIPAA is a law that tells you which outcomes you must achieve for one specific kind of data. SOC 2 is a report in which an independent accountant gives an opinion on controls you designed yourself. Comparing them like two checklists is a category error — and it is the reason vendor claims are so easy to misread.
HIPAA
A legal obligation you are under.
SOC 2
An assurance artifact you commission.
02Framework hierarchy
From the top of each framework down to what an engineer actually builds
Both frameworks descend from broad objectives to concrete implementation — but they hand the specifics over to the organization at different points, and only one of them ends with an independent examination.
Your policies, procedures & technical controlsorganization-defined
Not enumerated by the regulation. This layer is yours.
“Addressable” does not mean optional.
An Addressable specification requires you to assess whether it is a reasonable and appropriate safeguard in your environment. The assessment is mandatory. What follows it has exactly three legitimate outcomes:
1Implement it
The specification is reasonable and appropriate in your environment, so you implement it as written.
2Implement an equivalent alternative
The specification as written does not fit, but an alternative measure achieves the same purpose. Implement the alternative and document the reasoning.
3Document why it is not reasonable and appropriate
Neither the specification nor an alternative is reasonable and appropriate. You must record why — the analysis is the deliverable, and it is auditable.
What is never permitted: skipping the assessment. The obligation to assess is itself mandatory, and the reasoning must be documented under § 164.316.
The full matrix, filtered
Transcribed from the official Security Standards Matrix.
Technical Safeguards
The technology and the policy governing it that protects and controls access to ePHI.
The category executives most expect to be a technical checklist — and the one that most often surprises them. It names five standards and seven specifications, five of which are addressable. It does not name specific algorithms, key lengths, products, or protocols.
Access Control§ 164.312(a)(1)
Allow access to ePHI only to persons or software programs that have been granted access rights under § 164.308(a)(4).
R
Unique User Identification(a)(2)(i)
Assign a unique name and/or number for identifying and tracking user identity.
R
Emergency Access Procedure(a)(2)(ii)
Establish procedures for obtaining necessary ePHI during an emergency.
A
Automatic Logoff(a)(2)(iii)
Terminate an electronic session after a predetermined time of inactivity.
A
Encryption and Decryption(a)(2)(iv)
Encrypt and decrypt ePHI. Note: this is the at-rest specification, and it is addressable — not required — under the rule in force.
Audit Controls§ 164.312(b)
Implement hardware, software, and/or procedural mechanisms that record and examine activity in systems containing or using ePHI.
Integrity§ 164.312(c)(1)
Protect ePHI from improper alteration or destruction.
A
Mechanism to Authenticate ePHI(c)(2)
Corroborate that ePHI has not been altered or destroyed in an unauthorized manner.
Person or Entity Authentication§ 164.312(d)
Verify that a person or entity seeking access to ePHI is the one claimed.
Transmission Security§ 164.312(e)(1)
Guard against unauthorized access to ePHI being transmitted over an electronic communications network.
A
Integrity Controls(e)(2)(i)
Ensure that electronically transmitted ePHI is not improperly modified without detection until disposed of.
A
Encryption(e)(2)(ii)
Encrypt ePHI whenever deemed appropriate. This is the in-transit specification, and it too is addressable.
Also binding, but outside the 18/36 matrix
A frequent source of conflicting numbers in vendor material. The Appendix A matrix covers only the three safeguard categories. Two further sections of the Security Rule are equally binding and are not counted above.
Organizational Requirements
Sets what a business associate contract must say — including that the business associate will comply with the Security Rule and flow equivalent obligations down to its own subcontractors. This is the machinery behind the BAA.
Policies and Procedures and Documentation
Documentation must be retained for six years from the date of creation or the date it was last in effect, whichever is later; made available to those responsible for implementing it; and reviewed periodically and updated in response to environmental or operational changes. All three specifications are Required.
Proposed — not in force
A pending rulemaking would remove the Required/Addressable distinction entirely.
HHS OCR issued a Notice of Proposed Rulemaking on 27 December 2024 (published 6 January 2025) that would make nearly all implementation specifications required, with limited exceptions, and would explicitly mandate measures including encryption of ePHI at rest and in transit, multi-factor authentication, and network segmentation.
The comment period closed 7 March 2025 with several thousand comments received. As of September 2026 no final rule has been issued and the regulatory agenda points to 2027 for final action. Everything else on this page describes the rule ACTUALLY IN FORCE today — plan for the proposal, but do not report against it.
03Terminology translator
The same idea, wearing two different vocabularies
Much of the friction between compliance and engineering teams is lexical. These are conceptual bridges — helpful for orientation, dangerous if mistaken for an official crosswalk.
HIPAA
Closest SOC 2 concept
Fidelity
Safeguard Category
The three top-level groupings of the Security Rule: § 164.308, § 164.310, and § 164.312.
Trust Services Category
The five categories an examination may cover. Unlike HIPAA's three, these are selectable — you choose which are in scope.
Both are the broadest grouping level. But HIPAA's three categories are all mandatory and organize by TYPE OF CONTROL, while SOC 2's five categories are selectable and organize by TYPE OF PROMISE to the customer.
Standard
An objective-level requirement. 18 of them across the three safeguard categories. Every standard is mandatory.
Criterion
An objective-level statement the organization's controls must satisfy. Fixed and numbered by the AICPA.
The strongest parallel on this table. Both state an objective without prescribing the mechanism. 'Implement technical policies and procedures that allow access only to those granted rights' and CC6.1 are asking materially similar questions.
Implementation Specification
A more granular expectation sitting under a standard. 36 in total: 14 Required, 22 Addressable.
Point of Focus
Characteristics that help management and the auditor interpret a criterion. The AICPA states you are not required to assess whether each one is addressed.
A tempting parallel that breaks down under pressure. Both add granularity below the objective — but a HIPAA implementation specification is part of the binding regulation, while a point of focus is explicitly advisory. Do not treat them as equivalent in weight.
The measure you actually implement
HIPAA almost never names the mechanism. Your SSO configuration, key management, and log pipeline are your answer to the standard — not the rule's.
Organization-defined control
A specific, testable statement of something the company does, written by the company and listed in the report.
Here the two frameworks genuinely converge. In both cases the concrete control is the organization's own design decision. The difference is that SOC 2 forces you to write it down in a form an auditor can test, and HIPAA does not.
Documentation and evaluation
Written policies and procedures retained six years, plus periodic technical and non-technical evaluation. Self-assessed by default.
Audit evidence and tests of controls
Sampling, inspection, observation, and re-performance by a third party, with the results printed in the report.
The sharpest asymmetry between the frameworks. HIPAA requires you to document and evaluate; it does not require anyone independent to check. SOC 2's entire value proposition is that somebody independent did check, and said so in writing.
Business Associate Agreement
A contract legally binding a vendor to safeguard ePHI and to flow the same obligations down to its subcontractors.
Vendor risk management controls
Controls for assessing and managing risks associated with vendors and business partners.
Both address third parties, from opposite directions. A BAA is a legal instrument that transfers regulatory obligation. CC9.2 is a criterion asking whether you manage vendor risk at all. A SOC 2 report is not a substitute for a BAA, and a BAA is not evidence of vendor risk management.
Risk Analysis
An accurate and thorough assessment of risks to the confidentiality, integrity, and availability of ePHI. The engine of the entire rule.
Risk assessment criteria
Specifying objectives, identifying and analyzing risk, considering fraud risk, and identifying significant change.
Conceptually close, materially different in scope. HIPAA's risk analysis is narrowly and specifically about ePHI, and OCR has repeatedly found deficient risk analyses to be the root of enforcement actions. CC3 is about enterprise risk to the entity's objectives generally.
These are conceptual parallels drawn to aid understanding — not official mappings. Neither HHS nor the AICPA publishes an authoritative crosswalk between HIPAA and the Trust Services Criteria, and satisfying a criterion never automatically satisfies a Security Rule requirement.
04What “HIPAA compliant” means
There is no certificate. There is a process you are always inside of.
No government body issues a HIPAA certification, and HHS endorses no private one. What exists instead is a sequence of obligations that begins with your role and never really ends.
Step 02 of 10
Conduct a risk analysis
Identify where ePHI lives, moves, and rests, and assess risks to its confidentiality, integrity, and availability.
This is the specification everything else hangs from. Because the rule is risk-based, you cannot evaluate whether a safeguard is 'reasonable and appropriate' without knowing what the risks are. An inventory of ePHI flows and systems is the practical prerequisite.
Where this goes wrong
The single most common finding in OCR enforcement. A vendor questionnaire, a penetration test, or a gap assessment against a checklist is not a risk analysis.
HIPAA tells you substantially WHAT outcomes and safeguards are required.
It is not a prescriptive checklist containing hundreds of universally identical technical controls.
The Security Rule names 18 standards and 36 implementation specifications. It names no products, no algorithms, no key lengths, and no session timeouts. Two compliant organizations can look completely different in implementation — because § 164.306(b) explicitly permits any security measures that let them reasonably and appropriately implement the standards.
The four general requirements
Ensure the confidentiality, integrity, and availability of all ePHI the entity creates, receives, maintains, or transmits.
Protect against any reasonably anticipated threats or hazards to the security or integrity of that information.
Protect against any reasonably anticipated uses or disclosures not permitted or required under the Privacy Rule.
Ensure compliance by the workforce.
Flexibility of approach
You may use any security measures that let you reasonably and appropriately implement the standards, weighing:
Size, complexity, and capabilities. A twelve-person startup and a national payer are not held to identical implementations.
Technical infrastructure, hardware, and software security capabilities. What the organization's actual environment can support.
Costs of security measures. Cost is a permitted consideration — but it is one factor among four, and it never justifies leaving a risk unaddressed.
Probability and criticality of potential risks to ePHI. The output of the risk analysis, which is what makes the whole rule risk-based.
There is no such thing as a HIPAA certificate
HHS states that it does not endorse or otherwise recognise private organisations’ HIPAA “certifications,” and that such certifications do not absolve a regulated entity of its legal obligations. A vendor holding a certificate from a compliance platform has bought an assessment, not a regulatory status. It may still be useful evidence — it is simply not what the word implies.
05What “SOC 2 compliant” means
A report with an opinion in it — not a certificate on a wall
Organisations do not become “SOC 2 certified.” They obtain a SOC 2 Type 1 or Type 2 report in which an independent CPA firm expresses an opinion. The distinction is not pedantry: the two report types say very different things.
Type 1 vs Type 2
The single most useful question to ask a vendor.
SOC 2 Type 2
Throughout a specified period
Were the controls suitably designed AND did they operate effectively across the whole period?
How to read it
This is the one to ask for. Then read three things: the period covered, the system boundary, and the exceptions in the testing tables.
What it covers
Everything a Type 1 covers
Operating effectiveness of controls throughout the review period
The practitioner's tests of controls and the results of those tests
Exceptions and deviations found during testing
What it does not
A guarantee that no incident occurred
Any period outside the stated examination window
Systems, products, or subsidiaries outside the described system boundary
In practice. The report enterprise buyers normally expect. Periods commonly run three to twelve months, with twelve months preferred for continuous coverage.
The five Trust Services Categories
Scope is a choice. A vendor selects which categories the examination covers, and that choice determines what the report can possibly tell you.
Security
“Is the system protected against unauthorized access, use, or modification?”
The foundational category. Uniquely, its complete criteria set is exactly the common criteria — the AICPA states that when Security is included, no additional control activity criteria are needed.
When it’s in scope
Included in the overwhelming majority of SOC 2 examinations. The AICPA describes it as 'addressed in most trust services engagements' and calls the case where it is not addressed 'uncommon' — so treat a SOC 2 report that excludes Security as a red flag worth asking about, rather than an impossibility.
Which category is actually mandatory?
Almost every source will tell you Security is required in every SOC 2. That is a good working assumption and a slight simplification of what the AICPA says. The common criteria (CC1–CC9) are common to all five categories, so they are engaged whichever category you select. Security is distinctive in that the common criteria alone constitute its complete set. The AICPA describes Security as addressed in most trust services engagements, and calls the case where it is not addressed uncommon — so a report excluding Security is not impossible, just a strong signal to ask why.
Seven things to check when a vendor hands you a report
1The opinion
Unqualified, qualified, adverse, or a disclaimer. A qualified opinion is not fatal, but it names something the auditor could not get comfortable with.
2The period and the gap
A Type 2 covering a period that ended fourteen months ago tells you about a company that no longer exists. Ask about the bridge letter.
3The system boundary
Which product, which environment, which subsidiary. Vendors frequently scope a report to one mature product line and market it as company-wide.
4Categories in scope
Security only, or Security plus Confidentiality and Availability? The cover page tells you how much of the vendor's promise was actually examined.
5Exceptions in the test tables
The most information-dense part of the report and the part almost nobody reads. Deviations, their causes, and management's response.
6Complementary user entity controls
Controls the report assumes YOU operate. If you do not, the vendor's assurance has a hole in it that is your responsibility.
7Subservice organizations
Carved out or inclusive. A carve-out means the sub-processor's controls were not tested in this report.
06The asymmetric overlap
A large shared middle — and two edges that never meet
This is the part most vendor conversations get wrong. The overlap is real and substantial, but it is asymmetric in both directions: each framework covers ground the other simply does not reach.
Overlapping, not nested.
The security and governance middle is large and real — an access review, an incident runbook, or a deprovisioning workflow can serve both frameworks at once. But the overlap is asymmetric: HIPAA reaches into legal territory SOC 2 never enters, and SOC 2 reaches into operational and contractual territory HIPAA never addresses.
Neither framework contains the other. A SOC 2 Type 2 report does not make a vendor HIPAA compliant, and HIPAA compliance produces no independently examined assurance artifact. Any claim that one 'covers' the other is wrong in a way that creates real risk.
On the “80% overlap” figure
You will see figures like '80% overlap' quoted widely. No such official statistic exists — the number depends entirely on which categories are in scope, how controls are written, and what you choose to count. Treat any precise overlap percentage as marketing.
All concepts
Shared security & governance
Access control
Who can reach what, and on what authority.
HIPAA perspective
§ 164.312(a)(1), § 164.308(a)(4)
A standard requiring technical policies and procedures that allow access only to those granted rights, plus administrative requirements for authorizing access consistent with the minimum necessary principle. Scoped specifically to systems holding ePHI.
SOC 2 perspective
CC6.1 – CC6.3
Criteria covering logical access security software, infrastructure, and architecture over protected information assets; registration and authorization of new users; and management of access based on roles and responsibilities. Scoped to the whole system described in the report.
One implementation, two questions. The control you build can serve both frameworks — but each asks about it differently, and satisfying one auditor’s question does not automatically answer the other’s.
07Control explorer
Pick a control. See what each framework actually asks of it.
The pattern repeats across almost every entry: HIPAA states an outcome and leaves the mechanism to you, while SOC 2 tests a sentence your own company wrote. Search or filter to find a control.
15 controls
Identity
Multi-Factor Authentication
Requiring more than one factor to authenticate a user.
HIPAA
Where it maps
Person or Entity Authentication; Access Control; Risk Analysis
Safeguard category
Technical / Administrative
Citations
HIPAA does not say 'every system must use MFA' in those words anywhere. It requires you to verify that a person seeking access is who they claim to be, and to reduce risks to a reasonable and appropriate level. In a modern internet-facing environment holding ePHI, a risk analysis will almost always conclude MFA is reasonable and appropriate — which is how an unnamed technology becomes a practical expectation. The pending 2024 NPRM would name MFA explicitly.
SOC 2CC6.1CC6.2
Typical organisation-defined control
“MFA is enforced for all users accessing production systems and the corporate identity provider.”
A population export of users with MFA status, sampled by the auditor
Attempted-login evidence or policy-block screenshots
Exception listing for service accounts, with compensating controls
The auditor does not test 'MFA' in the abstract — it tests the sentence the company wrote. A control scoped to 'production systems' says nothing about the admin console of the billing SaaS.
08AI coding tools
Why it matters whether your AI coding tool is HIPAA-covered or SOC 2 audited
The honest answer is: it depends entirely on what leaves your boundary. The same tool can be almost irrelevant to HIPAA in one team and squarely regulated in another — and the variable is data flow, not the vendor.
The exposure gradient
Drag or click through the rungs. Notice that SOC 2 relevance starts high and stays high, while HIPAA relevance is near-zero until a specific line is crossed.
Source code only
What flows to the vendor. Repository contents, diffs, file trees. No customer data, no production credentials, no logs.
HIPAA relevanceMinimal
No PHI is disclosed to the vendor, so the vendor is not acting as a business associate with respect to this activity and no BAA is triggered. HIPAA has little direct relevance TO THE TOOL ITSELF — which does not mean the tool is low risk.
SOC 2 relevanceHigh
Everything at stake here is confidentiality of intellectual property and the vendor's operational discipline. This is precisely what SOC 2 examines and HIPAA does not.
What to ask the vendor at this rung
Is the SOC 2 report a Type 2, and what period does it cover?
Is Confidentiality in scope, or Security only?
Is customer code used for model training, and is that the default or opt-out?
What is the retention period for prompts and completions?
Are SSO, SCIM, and audit logs available on our plan tier?
Guardrail
Treat this as the target state. Keeping the tool at this tier is itself a control worth engineering for.
A
Code only, no PHI
The most common situation in healthcare engineering organizations, and the one most often over-escalated. Because the company is a covered entity or business associate, procurement reflexively asks 'are they HIPAA compliant?' — a question that, for this usage, barely engages.
HIPAA verdictMinimal
Little direct relevance to the coding tool itself. No PHI is disclosed, so the vendor is not a business associate for this activity and no BAA is triggered by it.
SOC 2 verdictHigh
Highly relevant, and the right question to be asking. The vendor holds your proprietary source code — the confidentiality, retention, and access-control questions are exactly the ones SOC 2 examines.
What actually matters here
SOC 2 Type 2, and its scope
Check the period, the system boundary, and whether Confidentiality is in scope alongside Security.
Model training policy
Is your code used to train models? Is the exclusion contractual, and does it apply to your plan tier by default?
Retention
How long are prompts, completions, and indexed context stored — and can you set it to zero?
Code confidentiality
Tenant isolation, which vendor personnel can access content, and under what break-glass controls.
Enterprise identity
SSO, SCIM provisioning, and admin-visible audit logs — often gated behind enterprise tiers.
Subprocessors and residency
Which model providers and infrastructure vendors sit behind the product, and in which regions.
Secrets protection
Your real exposure here is usually a credential in a config file being swept into context, not a compliance failure.
09Without PHI
Why SOC 2 still matters when HIPAA does not apply at all
Remove every trace of health data and a serious assurance question survives — because what you hand a coding tool is valuable on entirely different grounds.
HIPAA asks
“How are you protecting regulated healthcare information?”
One data type, defined by statute.
SOC 2 asks
“Can customers trust the way you operate and protect their information and systems?”
Whatever information you hold and whatever you promised about it.
Strip out every trace of PHI and a serious assurance question remains — because the data you hand a coding tool is valuable on its own terms.
Proprietary source code
Often the company's single most valuable asset, and the entire point of the tool.
System architecture
How the platform is put together, including where its trust boundaries sit.
Credentials and secrets
Accidentally exposed in config files, test fixtures, and pasted stack traces. The most consequential item on this list.
Internal APIs
Undocumented endpoints and their authentication behaviour.
Security designs
Authorization logic, rate limiting, fraud checks — a map of what to bypass.
Customer information
Test data, support tickets, and fixtures that started life as real records.
Pricing, entitlements, and algorithms that encode competitive advantage.
None of this is PHI, so HIPAA has nothing to say about any of it. All of it is exactly what the Trust Services Criteria — particularly Confidentiality and the CC6 access criteria — exist to examine. SOC 2 remains highly relevant precisely where HIPAA does not apply.
10Executive summary
The whole thing, compressed
If you retain nothing else from this page, retain this.
HIPAA
regulation
A federal regulation, not a certification
Scoped to PHI and ePHI in healthcare
Risk-based: implementation scales with your environment
No government certification exists; HHS endorses no private one
Compliance is organization- and context-dependent, and continuous
Enforced by HHS OCR with civil and criminal penalties
SOC 2
assurance
A voluntary assurance examination, not a law
Broad service-organization scope across any industry
Measured against the AICPA Trust Services Criteria
61 criteria total: 33 common, plus category-specific criteria
Controls are designed by the organization, not dictated by the criteria
Opinion issued by an independent licensed CPA firm
Type 1 (design, one date) or Type 2 (design + operation, over a period)
Why healthcare technology companies end up holding both
They answer different questions for different audiences. HIPAA answers to a regulator about a data type; SOC 2 answers to a customer about an organization. Neither substitutes for the other, and the shared security and governance middle means the marginal cost of the second is far lower than the first.
Regulatory obligation
HIPAA is the floor you are legally standing on if you touch PHI.
Independent assurance
SOC 2 is the evidence an enterprise buyer's security team will actually accept in a review.
Shared implementation
Access control, logging, incident response, vendor management, and policy work serve both at once.
Distinct residue
BAAs, breach notification, and ePHI risk analysis stay HIPAA-only. Processing integrity, availability commitments, and independent period testing stay SOC 2-only.
Six claims, and what they actually mean
A field guide for the next vendor call.
“We're HIPAA certified.”
No such certification exists. HHS issues none and endorses none. At best this means a self-assessment or a private attestation with no regulatory standing.
“We're SOC 2 certified.”
SOC 2 produces a report containing an opinion, not a certificate. The phrasing is a reliable signal that nobody on the vendor's side has read the report.
“We're SOC 2 compliant, so we're HIPAA compliant.”
The overlap is real but partial and asymmetric. SOC 2 does not produce a BAA, an ePHI-scoped risk analysis, or breach notification obligations.
“We have a SOC 2.”
Ask which type, which period, which categories, and which system. A Type 1 from two years ago covering Security only is a very different artifact from a current twelve-month Type 2.
“Encryption is required by HIPAA.”
Both encryption specifications are Addressable under the rule in force. Encryption is near-universal in practice for good reasons — but the requirement is to assess and document, not to implement unconditionally. The pending NPRM would change this.
“Addressable means optional.”
It means assess, then implement, substitute, or document why not. Skipping the assessment is the one thing never permitted.