HIPAA vs SOC 2: do you need both?

If you're building software for healthcare customers and you've just closed your first SOC 2 audit, you've probably asked the question that trips up nearly every growth-stage engineering team: does a SOC 2 report satisfy HIPAA, or do you need a separate HIPAA compliance program on top of it? The short answer is that SOC 2 and HIPAA solve different problems for different audiences, and most companies selling into healthcare end up needing both. This distinction matters more than it used to, because compliance automation platforms like Drata have made it easy to check the "SOC 2 done" box while leaving harder technical safeguards — especially around software supply chain integrity — only partially addressed. Below, we break down what SOC 2 and HIPAA actually require, where they overlap, where automation platforms fall short, and how Safeguard closes the supply chain security gap that neither framework was originally built to enforce.

What's the Actual Difference Between HIPAA and SOC 2?

The confusion starts because both frameworks touch security controls, but they exist for different reasons.

HIPAA is a federal law. The HIPAA Security Rule requires any organization that creates, receives, maintains, or transmits protected health information (PHI) — covered entities and their business associates — to implement administrative, physical, and technical safeguards. There is no such thing as a "HIPAA certification" issued by a government body; compliance is a legal obligation enforced through audits, complaints, and breach investigations by the HHS Office for Civil Rights, and penalties can include fines and corrective action plans.

SOC 2 is not a law. It's a voluntary attestation report, defined by the AICPA's Trust Services Criteria, produced by an independent CPA firm after evaluating your controls against one or more of five categories: security, availability, processing integrity, confidentiality, and privacy. Customers ask for a SOC 2 report as a form of vendor due diligence — it's a trust signal, not a legal requirement.

In practice, this means a clean SOC 2 Type II report tells a healthcare customer "an auditor reviewed this vendor's controls and found them operating effectively." It does not, by itself, satisfy the specific technical safeguards HIPAA requires around PHI, such as audit controls tied to individual PHI access events, encryption specifications, or breach notification timelines. That's the core reason most SaaS vendors selling into healthcare pursue SOC 2 first as a market credential, then layer on a HIPAA compliance program once they're actually handling PHI.

Why Compliance Automation Platforms Like Drata Don't Close the Software Supply Chain Gap

Drata is, by its own public positioning, a compliance automation and GRC platform: it connects to your cloud infrastructure, HR system, and policy documents to continuously collect evidence and monitor controls for frameworks including SOC 2, ISO 27001, and HIPAA. That's a genuinely useful function — it replaces a lot of manual screenshot-and-spreadsheet evidence gathering auditors used to require.

But evidence automation and control automation are not the same thing as closing a technical gap. A platform that automates evidence collection for a control like "vulnerability management is performed" still depends on the underlying engineering practice actually producing accurate, complete evidence. Two concrete, verifiable dimensions worth naming:

• Evidence source, not control implementation. Drata's core workflow (per its own product description) is integrating with existing systems — cloud providers, identity providers, ticketing tools — to pull evidence that a control exists and ran. It is not a source of software composition analysis, SBOM generation, or build-provenance data; those artifacts have to come from somewhere else in your toolchain and then get fed in as evidence.
• Framework breadth vs. supply chain depth. Compliance automation platforms are built to span dozens of frameworks (SOC 2, ISO 27001, HIPAA, PCI DSS, GDPR, and more) with a shared control library. That breadth is valuable for coordinating an audit calendar, but it means the software supply chain–specific controls — third-party dependency risk, build integrity, artifact signing, SBOM accuracy — get treated as generic "vulnerability management" checkboxes rather than a dedicated engineering discipline.

Safeguard, by contrast, is purpose-built around the software supply chain itself: generating and validating SBOMs, scanning dependencies and container images, verifying build provenance, and surfacing exploitable risk in what your engineers actually ship. That's a narrower scope than a full GRC platform, and it's meant to be — it's the evidence source, not a replacement for audit-cycle management.

Where Do HIPAA and SOC 2 Overlap on Vulnerability and Change Management?

This is where the two frameworks actually converge, and where the software supply chain question becomes unavoidable for both.

The HIPAA Security Rule's technical safeguards include requirements for integrity controls (protecting PHI from improper alteration or destruction) and for reasonable and appropriate security measures against reasonably anticipated threats — which HHS guidance has repeatedly tied to patching known vulnerabilities in software used to handle PHI. SOC 2's Common Criteria include CC7.1 and CC8.1, which speak directly to detecting and remediating vulnerabilities and managing changes to infrastructure and software in a controlled way.

Neither framework says "you must maintain an SBOM" or "you must verify build provenance" in those exact words — that would be overstating what's written. But both frameworks require you to demonstrate that you know what's in your software, that you can detect when a dependency introduces a known vulnerability, and that changes to production systems go through a controlled process. Open-source dependency sprawl and unverified build pipelines are precisely the places those controls tend to break down in real audits, because the evidence — "here is what's actually running, and here is proof it wasn't tampered with" — often doesn't exist in a form an auditor can verify.

Do You Need Both HIPAA and SOC 2?

For most B2B software companies with healthcare customers, yes — but sequencing and scope differ:

• If you never touch PHI (you sell infrastructure tooling, analytics, or dev tools to healthcare companies without handling patient data yourself), SOC 2 alone is usually the market expectation, and HIPAA may not apply to you as a legal matter.
• If you're a business associate under HIPAA — you store, process, or transmit PHI on behalf of a covered entity — HIPAA compliance is a legal requirement regardless of whether you pursue SOC 2. You cannot substitute a SOC 2 report for a HIPAA risk analysis and safeguards program.
• Most growth-stage healthcare SaaS vendors end up doing both: SOC 2 because customers and procurement teams ask for it as a trust signal, and HIPAA because it's legally required once PHI is in scope. Many compliance programs (including Drata's, per its published framework list) explicitly support mapping shared controls across SOC 2 and HIPAA to avoid duplicating evidence work.

The practical takeaway: treat SOC 2 and HIPAA as complementary obligations with overlapping but distinct control sets, not as interchangeable certifications. A shared controls-mapping exercise reduces duplicate work, but it doesn't eliminate HIPAA-specific requirements like PHI-specific access logging or breach notification procedures.

Compliance Automation vs. Supply Chain Security: Two Different Layers

It's worth being explicit about where each type of platform sits in a compliance program, because conflating them is how gaps get missed:

1. GRC/compliance automation layer (Drata's category): coordinates the audit process, maps controls to frameworks, collects evidence from connected systems, and tracks remediation tasks across the organization. This is where you manage the relationship with your auditor and demonstrate program-level maturity.
2. Software supply chain security layer (Safeguard's category): produces the underlying technical evidence about what's actually in your software — dependency inventories, SBOMs, vulnerability findings tied to real exploitability, build and artifact provenance. This is where the evidence for controls like CC7.1, CC8.1, and HIPAA's integrity and vulnerability-related safeguards actually gets generated.

A mature compliance program needs both layers, and they're meant to feed each other: supply chain security tooling generates accurate, continuous evidence; the GRC platform organizes that evidence against your framework requirements and audit calendar. Trying to run either layer without the other tends to produce the same failure mode — either a well-organized audit trail built on shallow technical evidence, or strong technical controls that never get mapped to what an auditor is actually asking for.

How Safeguard Helps

Safeguard is built for the layer that compliance automation platforms don't cover: proving, with real technical evidence, what's actually running in your software supply chain. For teams navigating HIPAA and SOC 2 in parallel, that means:

• SBOM generation and validation that gives you an accurate, continuously updated inventory of every dependency touching systems in scope for PHI or SOC 2 audit boundaries — the raw material auditors increasingly ask for under both frameworks' vulnerability and change management criteria.
• Dependency and container scanning tied to exploitability context, not just CVE counts, so vulnerability management evidence reflects actual risk rather than noisy scanner output that slows down remediation and audit review.
• Build and artifact provenance verification, so you can demonstrate integrity controls — that what shipped to production is what was actually built and reviewed — which maps directly to HIPAA's integrity safeguards and SOC 2's processing integrity and change management criteria.
• Evidence that plugs into your existing GRC workflow, whether that's Drata, another compliance automation platform, or a manual audit process, so supply chain findings become audit-ready evidence rather than a separate spreadsheet your security team maintains by hand.

If your team already has a GRC platform handling audit coordination and evidence collection, Safeguard is designed to sit underneath it, generating the software supply chain evidence that platform was never built to produce on its own. The question isn't compliance automation or supply chain security — for HIPAA and SOC 2 both, you need the technical depth underneath the audit-ready surface.