A healthtech engineering team I worked with had just closed out a clean SOC 2 Type II audit. Zero exceptions. Champagne emoji in Slack. Two weeks later, product asked for an AI agent that could pull prior authorization status for case workers, built on Bedrock. An engineer wired it to the eligibility API in an afternoon. It worked in the demo: ask about a member, get an answer.
Except the agent, doing exactly what it was told, called the eligibility tool and got back the full member record: SSN, address, full claims history, all of it, when the caseworker only needed a yes or no on one procedure. Nothing about that shows up as a SOC 2 finding. Access was controlled. Encryption was in place. The audit log was pristine. It’s still a HIPAA minimum necessary violation, and the SOC 2 report the team was so proud of never tested for it.
That gap is the real version of the question CTOs ask me constantly as they scale: do we need both HIPAA and SOC 2, or does having one basically cover the other? Not the dictionary-definition version of the question. The version where money, engineering time, and actual PHI exposure are on the line.
What HIPAA Actually Requires
HIPAA isn’t a certification. Nobody hands you a badge. It’s a federal law that applies the moment you’re a covered entity or a business associate touching protected health information (PHI), and compliance is a state you maintain and can be investigated against, not an audit you pass once a year.
Three rules do the actual work: the Privacy Rule (what you can do with PHI and what rights patients have over it), the Security Rule (the administrative, physical, and technical safeguards you have to implement), and the Breach Notification Rule (a 60-day clock to notify affected individuals, HHS, and in large enough breaches, the media). Getting HIPAA compliance on AWS mostly means operating inside those three rules using AWS’s HIPAA-eligible services and a signed Business Associate Agreement (BAA), not memorizing the statute.
The consequence of getting it wrong isn’t a lost deal. It’s HHS Office for Civil Rights (OCR) enforcement. The 2026 civil penalty schedule runs from $145 per violation at the lowest tier up to $2,190,294 per violation category at the top, depending on whether the organization exercised reasonable diligence or showed willful neglect.
What SOC 2 Actually Requires
SOC 2 is a voluntary attestation built around the AICPA’s Trust Services Criteria, and a CPA firm, not a government agency, issues the opinion. Nothing in federal or state law requires it. Enterprise procurement does, in practice: past a certain deal size, a hospital system’s security team will ask for it before signing, full stop.
Five criteria exist: Security (mandatory, often called the “common criteria”), Availability, Processing Integrity, Confidentiality, and Privacy. Most companies scope Security plus Availability and Confidentiality to start, and add Privacy later if a buyer specifically asks. A Type I report attests to control design at a single point in time; a Type II report attests to operating effectiveness over an observation window, typically three to twelve months, and it’s the one buyers actually want. SOC 2 compliance on AWS leans hard on evidence AWS already generates: CloudTrail, Config, IAM Access Analyzer, GuardDuty findings. That’s why most SOC 2 programs on AWS end up with a similar architecture regardless of what the company does.
Skip it, and the consequence isn’t a fine. It’s a stalled or lost enterprise contract, or months of filling out custom security questionnaires instead of handing over one report.
The Core Differences at a Glance
| HIPAA | SOC 2 | |
|---|---|---|
| Legal status | Federal law, mandatory if PHI is in scope | Voluntary, market-driven |
| Who enforces it | HHS Office for Civil Rights | No enforcer; a CPA firm issues an opinion |
| What you get at the end | Nothing to show a prospect, an ongoing compliance posture | A signed report (Type I or Type II) |
| Consequence of failure | Civil penalties, breach notification duties, possible criminal referral | Lost deals, damaged trust, no direct legal penalty |
| What triggers scope | You handle PHI as a covered entity or business associate | A customer or the market expects independent assurance |
| Audit cadence | No formal audit; ongoing, self-driven risk analysis | Observation window (3 to 12 months), renewed annually |
Where the Two Frameworks Actually Overlap
Both frameworks are answering a version of the same question: can this organization be trusted with someone else’s data. That shared root is why the overlap is bigger than most comparison pieces suggest, and why building a program around one gives you a real head start on the other.
Concretely, here’s when each one shows up:
You need HIPAA if you’re a digital health platform storing patient records, a claims clearinghouse, a telehealth vendor recording visits that include PHI, or a SaaS vendor whose product touches an EHR integration on behalf of a covered entity. That last one catches people. You don’t need a doctor or patient logging into your product directly. If you’re processing PHI on behalf of someone who does, you’re a business associate, and HIPAA reaches you the same way it reaches the hospital.
You need SOC 2 if your buyers are enterprise or hospital-system procurement teams that require it as a gate, if you sell infrastructure, analytics, or API tooling to other software companies rather than to providers directly, or if you’d rather hand over one report than answer the same forty-question security survey every quarter for a different prospect.
You need both if you’re a healthtech SaaS company selling into hospital systems or payers. This is close to universal at that intersection: HIPAA because PHI is in scope the moment you touch it, SOC 2 because the buyer’s security team wants a CPA-signed opinion, not just your word.
Where They Genuinely Diverge
The overlap is real, but three gaps matter enough that treating the frameworks as interchangeable will burn you.
SOC 2’s Trust Services Criteria have no concept of minimum necessary. SOC 2 cares whether access is controlled, logged, and reviewed. It does not care whether the specific data returned by a specific call was the minimum required for the task, which is exactly the gap that bit the team in the Bedrock example above. That gap gets wider, not narrower, as more healthtech products ship agentic features.
HIPAA carries a hard breach notification timeline: 60 days to individuals, HHS, and in breaches affecting 500 or more people, local media. SOC 2 has no notification mandate at all. It expects an incident response plan and evidence you follow it, but nothing forces you onto a clock.
SOC 2’s Confidentiality and Privacy criteria are broader than PHI: trade secrets, business data, any non-health PII you handle. HIPAA only cares about PHI, but within that narrower scope, it goes deeper, covering patient rights to access and amend their own records, which SOC 2 was never built to test.
The Controls You Only Have to Build Once
This is the question that actually matters for planning: if you’ve got some of this covered for one framework, are you partially covered for the other? Mostly yes, with real exceptions.
| Control domain | SOC 2 expects | HIPAA expects | Carries over? |
|---|---|---|---|
| Access control | Unique IDs, MFA, least privilege, periodic access reviews | Unique user IDs, automatic logoff, emergency access procedure, workforce authorization | Mostly. Build role-based access with MFA and quarterly reviews once. HIPAA adds an emergency “break glass” access path with its own audit trail that most SOC 2 environments don’t build unless someone asks for it specifically. |
| Encryption | Expected to back confidentiality commitments | Addressable under the Security Rule, but in practice expected at rest and in transit for any ePHI | Fully. AWS KMS and TLS 1.2+ satisfy both. HIPAA is just less forgiving about gaps. |
| Logging and monitoring | Evidence controls are continuously monitored (CloudTrail, Config, Security Hub) | Audit controls that can reconstruct exactly who accessed which record and when | Heavily, at the infrastructure layer. A SOC 2 auditor wants to see that CloudTrail exists and alerts fire. An OCR investigator wants to see which employee opened which patient’s chart on which date. Same pipeline, narrower question. |
| Incident response | A documented, tested IR plan | A documented IR plan plus the 60-day notification clock and HHS reporting | Partially. Build one plan, but don’t assume it covers the legal notification math. That’s a separate workstream. |
| Risk assessment | Ongoing risk assessment tied to the Trust Services Criteria | A specific, named “risk analysis” under the Security Rule that OCR checks for in every investigation | Same discipline, different document. Settlements regularly cite “failure to conduct an accurate and thorough risk analysis” as a standalone finding, independent of whatever actually caused the breach. |
| Vendor risk | Vendor risk assessments, subprocessor tracking | A signed Business Associate Agreement | Not interchangeable. A SOC 2 vendor review is not a BAA, and this is the single most common gap I see. |
Vanta’s own control cross-mapping puts it at roughly this: an organization that already has SOC 2 is up to 65% of the way toward HIPAA, based on the technical controls both frameworks share. That number is about right in my experience, but it covers the technical layer. The legal and administrative artifacts, the BAAs, the HIPAA-specific risk analysis document, the breach notification procedure, don’t get built by having a mature SOC 2 program. You build those separately no matter how good your access control story is.
There’s a good illustration of that split in how AWS itself supports each framework. AWS publishes and maintains an official Config conformance pack for HIPAA Security through its awslabs GitHub organization, the same one referenced directly in AWS’s own migration and modernization documentation. There’s no AWS-published equivalent for SOC 2. The closest thing is a community-maintained pack under a separate, unofficial GitHub account, and its own template says plainly that SOC 2 is subject to interpretation by the attestor and that passing its Config rules doesn’t guarantee you’re satisfying SOC 2 controls. This is the practical shape of unified cloud compliance on AWS right now: one set of native controls, evaluated once, with an official automated mapping for HIPAA and only a best-effort community mapping for SOC 2.
Where AWS’s Own Tooling Draws the Line
AWS Audit Manager used to be the closest thing to a single tool spanning both frameworks’ evidence collection. It stopped accepting new customers on April 30, 2026. Existing customers keep using it as before, but anyone starting fresh now gets pointed toward Config and Security Hub instead, with no single AWS-native replacement that does what Audit Manager did across frameworks.
Security Hub has been picking up the slack. In July 2026, it added AI workload protection for Bedrock and SageMaker AI, plus monitoring for Microsoft Azure resources, so a crosswalk spanning more than one cloud has a real path to one dashboard instead of stitched-together evidence. AWS also published implementation guidance for HITRUST i1 that same month, worth flagging because more sophisticated health system buyers are starting to ask for HITRUST on top of, or instead of, SOC 2 plus HIPAA. If you’re early enough to be choosing your first framework, don’t assume SOC 2 plus HIPAA is the final destination.
The Mistakes That Show Up in Almost Every Audit
Treating a SOC 2 vendor security review as a substitute for a signed BAA is the most common one. SOC 2 asks whether you have a vendor risk process. It never asks whether you’ve signed a specific legal contract with a specific subprocessor. A company can pass SOC 2 cleanly and still have zero BAAs in place with vendors touching PHI, and not notice until an OCR investigation asks for one.
Skipping a HIPAA-specific risk analysis because “we already did one for SOC 2” is the second. OCR wants a document that speaks directly to ePHI risk, not a general InfoSec risk register repurposed with a new cover page.
The third is newer: assuming existing SOC 2 controls automatically extend to an AI or agentic feature. They don’t, for the same reason the opening example didn’t work. Access control and audit logging tell you an agent’s calls were authorized and recorded. Neither one tells you the agent only returned what the task actually needed.
One edge case worth knowing: HIPAA’s reach doesn’t stop at your direct contract. Since the 2013 Omnibus Rule, a subcontractor to a business associate is itself bound by HIPAA, even with zero direct relationship to a covered entity. A lot of B2B infrastructure vendors assume they’re outside HIPAA’s reach because they’re not customer-facing, and that assumption is exactly backward if PHI flows through their system at any point in the chain.
None of this is abstract risk. Verizon’s 2026 Data Breach Investigations Report tracked 1,492 healthcare security incidents with 1,438 confirmed data disclosures, and found that roughly a third involved a third party, which is precisely the BAA gap most teams discover too late.