Start with the fact that explains the whole situation: there is no such thing as HIPAA certification. No government body certifies compliance, and no private firm can confer a status that the regulator does not recognise. Anyone selling you a HIPAA certificate is selling you their own opinion in a nice font. That absence is exactly why HIPAA and SOC 2 end up paired so often: buyers need something independent to look at, and a SOC 2 examination is the closest thing available.
That absence is precisely why health tech buyers ask for SOC 2. A hospital’s vendor risk team, a payer’s procurement function or a digital health platform bringing you on as a subprocessor needs independent evidence that your controls exist and operate. HIPAA does not produce such an artefact. A SOC 2 examination, performed by a licensed CPA firm and covering a defined period, does. So the market settled on SOC 2 as the closest available proxy, and you end up needing both — the legal obligation and the artefact that demonstrates you take it seriously.
The rest of this post is about not paying for that twice. As with anything HIPAA-related, specifics depend on your organisation, your role and your data, and none of this is legal advice.
What each one actually is
HIPAA is law. If you are a covered entity or a business associate handling protected health information, the Privacy, Security and Breach Notification Rules apply to you whether or not anyone audits you. Enforcement comes from the regulator, typically after a complaint or a breach. The instrument that binds you to a customer is a business associate agreement, and it flows down to your subcontractors who handle PHI.
SOC 2 is an examination against the AICPA trust services criteria, resulting in a report with a CPA firm’s opinion. It is voluntary, driven by customers rather than regulators, and covers whatever scope and criteria you and your auditor define.
They answer different questions. HIPAA asks “are you meeting your legal obligations.” SOC 2 asks “can an independent examiner confirm that the controls you describe were designed appropriately and operated over this period.” A clean SOC 2 does not make you HIPAA compliant, and a signed BAA does not tell your customer anything about whether your offboarding process works.
Where the work genuinely overlaps
Most of it. The Security Rule’s administrative, physical and technical safeguards were written years before the current trust services criteria, but they are both describing a competent security programme, so the control set converges hard.
| Security Rule area | Typical SOC 2 counterpart |
|---|---|
| Security management process, risk analysis and risk management | Risk assessment criteria — identifying and analysing risks to objectives |
| Workforce security, authorisation and clearance | Logical access provisioning, background checks, role definitions |
| Information access management and access establishment | Access control, least privilege, periodic access reviews |
| Security awareness and training | Training criteria and evidence of completion |
| Security incident procedures | Incident identification, response, escalation and communication |
| Contingency plan, data backup, disaster recovery | Availability criteria, backup and restoration testing |
| Evaluation | Ongoing and separate evaluations, monitoring activities |
| Facility access controls, workstation security | Physical access controls, endpoint configuration |
| Access control, audit controls, integrity, transmission security | Logical access, logging and monitoring, encryption in transit and at rest |
| Business associate contracts | Vendor and subservice organisation management |
If your controls are built once and mapped to both frameworks, the same access review record, the same training completion export, the same restore test and the same incident ticket serve as evidence for each. There is no reason to run two access review processes.
Where they do not overlap
This is the part that gets missed, usually by teams who treat SOC 2 as the superset.
The Privacy Rule is largely absent from a Security-only SOC 2. Uses and disclosures, the minimum necessary standard, notices of privacy practices, individuals’ rights of access and amendment — these are HIPAA obligations with no counterpart in the Security trust services criteria. Adding the Privacy criteria to a SOC 2 covers some adjacent ground on personal information handling, but it is written against a different framework and does not map one-to-one.
Breach notification. HIPAA sets specific obligations about assessing whether an impermissible use or disclosure is a reportable breach, and notifying within defined timeframes, including business associate notification to the covered entity. SOC 2 asks whether you have an incident process. It does not test your regulatory notification clock.
Business associate agreements as legal instruments. SOC 2 vendor management will look at whether you assess and monitor vendors. It will not confirm you have executed BAAs with every subcontractor touching PHI, which is a contractual obligation with legal consequences.
Documentation retention. The Security Rule carries its own retention obligation for required documentation, on its own clock, independent of your SOC 2 evidence retention.
Scope of the risk analysis. The Security Rule expects analysis covering all ePHI wherever it is created, received, maintained or transmitted. Your SOC 2 risk assessment is scoped to the system in your description. Those are often different boundaries, and where they differ the HIPAA scope is usually wider.
The SOC 2 plus HIPAA report
There is a middle path worth knowing about. A SOC 2 examination can include additional subject matter beyond the trust services criteria — commonly a mapping of your controls to the HIPAA Security Rule standards and implementation specifications, tested and reported alongside the criteria. These are often called SOC 2 + HIPAA reports.
What that gives a buyer is one document showing both the trust services criteria results and how your controls line up against the Security Rule, with the same auditor’s testing behind both. For health tech companies whose customers are hospitals and payers, this frequently shortens the security review.
Three honest caveats. It is still not certification, and the report should not be represented as one. Not every firm offers it, and approaches to the mapping vary. And it adds scope, so it adds cost and effort — worth it if your buyers ask HIPAA questions in every review, less so if you have one health customer among thirty.
Running one programme instead of two
The practical mechanics come down to four decisions.
Map controls once, to both frameworks. Maintain a single control register with columns for the trust services criteria and the Security Rule specifications each control supports. Every new control gets mapped at the point it is created, not retroactively during fieldwork.
Keep the HIPAA risk analysis as its own identifiable document. Reuse the underlying work — the asset inventory, the threat analysis, the ratings — but do not let it dissolve into a SOC 2 risk assessment scoped to the platform. If a regulator asks for your risk analysis, “it is embedded in section three of our SOC 2 workpapers” is a poor answer, and the scope will not match anyway.
Build one evidence pipeline. Access reviews, training records, change approvals, backup restore tests, vulnerability remediation, incident tickets. Collect them in one place, on a schedule, with dates and approvers attached. The single largest source of duplicated effort is teams assembling the same artefacts twice for two different requesters.
Decide your SOC 2 criteria with health buyers in mind. Security is always included. Availability matters if you have uptime commitments and pairs naturally with contingency planning. Confidentiality is commonly added. Whether to add Privacy depends on what you do with personal information beyond the PHI your customers control, and is worth a conversation rather than a default.
What to do next
Take your three most recent health tech security questionnaires and highlight every question that a SOC 2 report would have answered outright. Then look at what is left. That residue — BAAs, breach notification timelines, Privacy Rule handling, risk analysis scope — is your genuine HIPAA-only workload, and it is usually smaller than teams fear once the overlap is stripped out.
Then check one thing in your control register: can you name, for each control, which Security Rule specification it supports? If the mapping does not exist, that is the artefact to build first, because everything else gets cheaper once it does.
Assurion performs HIPAA security risk analysis and SOC examinations as a licensed CPA firm, and can tell you whether a combined report fits your buyer base before you scope one.