SOC 2 vs. HIPAA vs. PCI DSS: what's required, what's optional

These three frameworks get lumped together in conversation but serve genuinely different purposes, apply to different situations, and require meaningfully different scopes of work.

What each one actually is, precisely

SOC 2 is an attestation (not a certification, technically) covering how a service organization manages customer data across five "trust service criteria" — security, availability, processing integrity, confidentiality, and privacy — though most companies only pursue the security criterion plus whichever others are relevant to their business. It's typically required by B2B customers, especially enterprise ones, as a condition of doing business, rather than by law.

HIPAA is a federal law, not an optional framework, that applies specifically to protected health information (PHI) — if you handle PHI as a covered entity or business associate, HIPAA compliance isn't optional regardless of your customers' preferences. It has specific, legally mandated requirements around access controls, encryption, breach notification timelines, and business associate agreements.

PCI DSS applies specifically to organizations that handle payment card data, with requirements scaled by transaction volume (four defined merchant levels, with different validation requirements at each). Critically, many companies can reduce their PCI scope dramatically by using a compliant third-party payment processor (Stripe, for instance) that keeps raw card data out of your systems entirely — the scope of what you need to comply with shrinks significantly if you're never actually touching card numbers.

How overlapping requirements actually work in practice

A company might need all three simultaneously — a healthtech SaaS product processing payments would plausibly need SOC 2 (for enterprise customer trust), HIPAA (because it handles PHI), and PCI DSS (because it processes payments) at once. The good news: a meaningful portion of the underlying technical controls overlap — access management, encryption standards, logging and monitoring, incident response — so building toward one properly often gets you most of the way toward the others, with framework-specific gaps to close rather than three entirely separate programs.

A concrete example of scoping this correctly

A digital health client initially assumed they needed comprehensive PCI DSS compliance because their platform processed patient payments. Our review found that by routing all payment processing through Stripe's hosted payment fields (rather than handling raw card numbers on their own servers), their PCI scope reduced to the simplest self-assessment tier — SAQ A — rather than the much more involved validation required if they were touching card data directly. This didn't eliminate PCI obligations entirely, but it meaningfully reduced the scope of work, letting us focus the majority of the compliance budget on their actual highest-stakes requirement: HIPAA, given the PHI they handled directly and couldn't outsource to a third party.

Where teams get stuck

The most common mistake is pursuing a framework because a competitor has it, without evaluating whether it's actually required for your specific business and data types. We start every compliance engagement by mapping which frameworks are genuinely applicable — legally required versus customer-preference-driven versus not relevant at all — before scoping any work.

How Ndakum approaches it

Compliance scoping is one of the first things we do in any Cybersecurity engagement — figuring out what's actually required for your specific business before building toward any framework.