A founder asked me last month which framework she "needed," as if there were a single right answer printed somewhere. There isn't. The honest reply is a question back: who's buying from you, and what data do you touch? Get those two answers and the framework picks itself. Get them wrong and you'll spend six figures certifying something nobody asked for.
So here's the map I draw on a whiteboard whenever someone asks. No acronym soup, no pretending every standard matters equally to you. Most teams need one to start, maybe two over time, and the rest are noise until a specific customer or regulator forces the issue.
The five that actually come up
There are dozens of security frameworks. In practice, B2B software companies run into the same handful over and over. Here's what each one is and, more usefully, who's going to ask you for it.
SOC 2 is the North American default. It's an attestation — a CPA firm examines your security controls and writes a report saying they're real and working. There's no certificate and no badge; the report is the thing you hand to a customer's security team. If you sell SaaS to US businesses, this is almost always the first one a deal stalls on. I covered the whole thing in the SOC 2 guide.
ISO/IEC 27001 is the international counterpart. Unlike SOC 2, it's a real certification: an accredited body audits your information security management system (ISMS) and issues a certificate that's valid for three years with annual check-ins. European, Middle Eastern, and APAC buyers tend to recognize ISO before they recognize SOC 2. The current version is ISO/IEC 27001:2022, and its Annex A lists 93 controls across four themes. More on that in ISO 27001 explained.
HIPAA isn't a certification at all — it's US law governing protected health information. If you store, process, or transmit health data on behalf of a covered entity (a hospital, a clinic, an insurer), you're a business associate and you sign a Business Associate Agreement. Nobody "certifies" you as HIPAA compliant; you attest to it yourself and live with the liability if you're wrong. Plenty of vendors get a HIPAA-scoped SOC 2 to give buyers third-party assurance, since HIPAA itself produces no audit report.
PCI DSS governs payment card data. If you store, process, or transmit cardholder data, the card brands require it. The good news for most SaaS companies: if you push payments to Stripe or a similar processor and never touch a raw card number, your PCI scope collapses to a short self-assessment questionnaire. The pain is reserved for teams that handle card data directly.
GDPR is the one people misclassify most. It's not a security framework and there's nothing to get certified in — it's EU privacy law. If you handle personal data of people in the EU, it applies, full stop. It shapes your data processing agreements, your breach notification timelines, and your data subject rights handling. Security controls support GDPR, but compliance is a legal and operational posture, not an audit you pass.
A nod to NIST and FedRAMP
Two more worth naming so you're not blindsided. NIST Cybersecurity Framework (CSF) is a voluntary US framework — a flexible structure for organizing your security program rather than something you certify against. It's common in enterprise risk conversations and as a backbone for internal programs. FedRAMP is the heavyweight: it's mandatory for cloud services sold to US federal agencies, it's expensive, and it takes the better part of a year or more. You'll know if you need FedRAMP because a government contract will tell you. Until then, ignore it.
Side by side
| Framework | What it is | Who needs it | Cert or attestation | Geography |
|---|---|---|---|---|
| SOC 2 | AICPA attestation report on security controls | US B2B SaaS | Attestation (report) | US-centric, recognized globally |
| ISO 27001 | Certification of an ISMS against an international standard | International buyers, global sales | Certification (3-yr cycle) | International |
| HIPAA | US law for protected health information | Anyone touching US health data | Self-attestation (law) | United States |
| PCI DSS | Card brand standard for cardholder data | Anyone handling card data | Self-assessment or audit | Global |
| GDPR | EU privacy law for personal data | Anyone handling EU residents' data | Legal compliance (no cert) | EU / EEA |
Your ad-network slot renders here
How to choose without overbuying
Two variables decide almost everything: your buyers' geography and the data you handle.
Sell SaaS to US companies and touch ordinary business data? Start with SOC 2 Security. It's what your questionnaires will demand and it's the cheapest path to unblocking deals.
Selling into Europe or to global enterprises, or your buyers keep naming ISO? Go ISO 27001 first, or run both. International procurement teams often won't accept a SOC 2 report as a substitute for an ISO certificate, and vice versa.
Touch health data? HIPAA is non-negotiable, and you'll likely pair it with a HIPAA-scoped SOC 2 so buyers get independent assurance. Handle raw card numbers? PCI DSS is required — but architect your way out of touching cards if you possibly can. Handle EU personal data? GDPR applies regardless of which security framework you pick; treat it as a parallel workstream, not an either/or.
The mistake I see most is a US-only company chasing ISO 27001 because it sounds more impressive, or a payments-adjacent startup ignoring PCI until an acquirer's due diligence team finds the gap. Match the framework to the demand. Impressing yourself is not a buyer requirement.
The second framework should never cost what the first one did. If it does, you scoped the first one badly or you're starting the second from scratch when you shouldn't be.
Why the second framework is cheaper
Here's the part that makes a multi-framework plan tolerable: the control sets overlap heavily. Access control, change management, encryption, vendor risk, incident response, logging, employee onboarding and offboarding — these show up in SOC 2's Common Criteria, ISO 27001's Annex A, HIPAA's Security Rule, and PCI DSS alike. The wording differs, the auditors differ, the evidence format differs. The underlying controls are largely the same controls.
That's why a company that already holds SOC 2 can usually add ISO 27001 for a fraction of the original effort. Most of the work is mapping existing controls to the new framework's language and producing a few ISO-specific artifacts, like the Statement of Applicability. The compliance automation platforms lean hard into this — they let you map one control once and satisfy multiple frameworks at the audit. I walk through the SOC-2-to-ISO path in detail in SOC 2 vs ISO 27001.
One overlap people skip until an auditor flags it: vendor risk. Every one of these frameworks asks how you vet the third parties touching your data. If your answer is a shrug, that's a gap in all of them at once. Build it once and it pays off across the board — start with our vendor risk guide.
The sequence I'd actually run
- Identify the demand. Read your questionnaires and your contracts. The framework your buyers ask for wins.
- Map your data. Health data, card data, EU personal data each pull in their own obligations regardless of your sales-driven choice.
- Do the first framework properly. Build real controls, not just the paperwork. The controls are the asset; the report or certificate is the receipt.
- Map, don't rebuild, for the second. When a second framework becomes worth it, reuse the controls you already operate and add only what's genuinely new.
- Treat GDPR and HIPAA as ongoing obligations, not projects with an end date. They don't expire when an audit window closes.
Frameworks feel like a maze when you treat them as a checklist to conquer. They're not. They're different audiences asking the same basic question — can I trust you with my data? — in different dialects. Learn to answer it once, in controls, and you can translate that answer into whichever framework the next deal happens to speak.