Compliance · Security
SOC 2 vs HIPAA vs PCI DSS: which framework actually applies to you
These three get lumped together constantly, "we need to get compliant", as if they were interchangeable. They are not. One is an attestation a customer asks for, one is a federal law that applies the moment you touch certain data, and one is a payment-industry contractual requirement. Knowing which actually applies to you changes what you build first.
TL;DR
- SOC 2 is a trust attestation, not a law. Nobody requires it by default; enterprise customers ask for it, and a CPA firm audits you against it.
- HIPAA is a US federal law. It applies automatically the moment you handle Protected Health Information, whether or not anyone asks. There is no official "HIPAA certified" badge, it is a compliance program you build and attest to.
- PCI DSS applies the moment you store, process, or transmit cardholder data. It is enforced through your contracts with payment processors and card networks, not government law.
- Most growing companies eventually need more than one. The good news: the underlying engineering controls, access control, logging, encryption, overlap heavily across all three.
SOC 2: the one customers ask for
SOC 2 is defined by the AICPA and tested against five Trust Services Criteria: Security is mandatory, Availability, Confidentiality, Processing Integrity, and Privacy are optional, add them only if a customer specifically requires them. A licensed CPA firm performs the audit, not a government agency. Type I assesses whether controls are designed correctly at a point in time; Type II assesses whether they actually operated correctly over 3 to 12 months, and is what most enterprise buyers actually want to see.
Nothing forces you to get SOC 2. What forces you is a sales cycle: an enterprise security questionnaire, a procurement team that will not sign without it. It is a business decision, triggered by who you are trying to sell to. See our SOC 2 readiness checklist for the actual engineering work, or try the free readiness quiz for a quick score.
HIPAA: the one that's already the law
HIPAA is not something you opt into. If your system stores, processes, or transmits Protected Health Information, PHI, on behalf of a covered entity (a healthcare provider, insurer, or clearinghouse) or as their business associate, HIPAA already applies to you today, whether or not you have done anything about it. There is no "HIPAA certification" issued by any government body, what exists is the Privacy Rule and Security Rule, and you build a compliance program against them: risk analysis, access controls, encryption, audit logging, and a signed Business Associate Agreement (BAA) with every covered entity before any PHI enters your systems.
The trigger is the data, not your sales pipeline. A healthtech startup with zero enterprise customers can still be squarely in HIPAA's scope on day one. See our DevOps for healthcare guide for what this means for infrastructure specifically.
PCI DSS: the one tied to card data
PCI DSS is maintained by the PCI Security Standards Council, founded by Visa, Mastercard, American Express, Discover, and JCB. It applies the moment you store, process, or transmit cardholder data, and your obligations scale with transaction volume and role: most companies self-assess with a Self-Assessment Questionnaire (SAQ), while very large merchants or service providers need a Qualified Security Assessor (QSA) to conduct a formal audit.
The single biggest lever most companies miss: if you route payments through a tokenizing processor (Stripe, Braintree, and similar) and never let raw card numbers touch your own servers, your scope shrinks dramatically, often down to the simplest SAQ tier. Companies that architect this correctly from day one avoid most of PCI's burden entirely; companies that build their own card-handling first and ask questions later inherit the full scope.
Side-by-side
| Framework | What it is | Triggered by | Who audits you | Legally required? |
|---|---|---|---|---|
| SOC 2 | Trust attestation (AICPA) | A customer or deal asking for it | Licensed CPA firm | No, contractual/sales-driven |
| HIPAA | US federal law | Handling PHI, at all | No certifying body; self-attested, OCR enforces | Yes, automatically |
| PCI DSS | Payment industry standard | Storing/processing/transmitting card data | Self (SAQ) or a QSA, by volume/role | Contractually, via card networks |
Where they overlap
The frameworks test different things, but the engineering foundation underneath them is largely the same work, done once and reused:
- Least-privilege access and enforced MFA, the first thing every auditor checks regardless of framework.
- Centralized audit logging with retention long enough to satisfy the strictest framework you're under.
- Encryption at rest and in transit, table stakes for all three.
- A written, tested incident response plan, not just a document nobody has read.
- Vendor and subprocessor tracking, especially relevant once a BAA or a QSA is involved.
Build this foundation once and each additional framework becomes incremental, mostly framework-specific documentation and scope, not a rebuild.
Common mistakes
- Assuming SOC 2 covers HIPAA or PCI. It doesn't. A SOC 2 report says nothing about PHI handling or cardholder data scope specifically.
- Treating PCI scope as "the whole company." Scope it to the systems that actually touch cardholder data; a tokenizing processor can shrink that to almost nothing.
- Waiting for a BAA request before building HIPAA controls. If you touch PHI, you're in scope now, not when someone asks.
- Chasing a framework nobody actually requires yet. Confirm what your next deal or your data actually triggers before spending months on the wrong one.
What to do next
Start by identifying which of these three your business and your data actually trigger, not which one sounds most impressive. From there, a Compliance Audit maps what you already have against the specific controls that framework requires and gives you a prioritized gap list instead of a guess.