These three names get used as if they were interchangeable badges, and they are not. SOC 2 is an auditor's report about your controls. ISO 27001 is a certificate that your security is run as a managed system. PCI DSS is a rulebook you must follow if you touch payment-card data. Different things, different audiences, different proof, but built on a single, unglamorous core: know what you are protecting, decide who can touch it, and show that the controls you claim actually work.

The quick version

  • SOC 2 is a US attestation report from a licensed CPA firm, against the AICPA's Trust Services Criteria. It says this independent auditor examined our controls and here is their opinion. Common with B2B software buyers.
  • ISO/IEC 27001 is a globally recognised certification proving you run an information security management system, a repeatable process for assessing risk and improving, not just a list of controls. Common in international and enterprise procurement.
  • PCI DSS is a mandatory standard, not a nice-to-have: if you store, process or transmit payment-card data, the card brands require it. Twelve requirements, enforced by your acquiring bank.
  • They overlap heavily. Treat them as one risk-driven security programme with three different reports coming out of it, not three separate projects competing for the same exhausted team.

The idea in depth: three frameworks, one job

Underneath the acronyms, all three answer the same question a customer, regulator or bank is really asking: can I trust you with data that matters? They just answer it in different formats, for different reasons. Get the format wrong and you spend a year producing a report nobody asked for; get the underlying work right and one effort feeds all three.

SOC 2 is the one most software buyers mean when they say "send us your security docs." It is an attestation examination performed under the American Institute of CPAs framework, specifically the 2017 Trust Services Criteria (with revised points of focus, 2022), and only a licensed CPA firm can issue the report. There are five trust categories, security, availability, processing integrity, confidentiality and privacy, and here is the part teams routinely miss: only security (the "common criteria") is mandatory. The other four are optional, included only if they matter to what you sell. There are also two report types. A Type I describes your controls at a single point in time; a Type II tests whether they actually operated over a period, typically a minimum of three months, often a year. The practical advice: don't reflexively scope in all five categories or rush a Type I to wave at a prospect. Pick the categories your buyers care about, and budget for a Type II, a Type I proves you wrote the policy, not that anyone followed it.

ISO/IEC 27001 comes at trust from a different angle. It is an international standard, certified by an accredited body, and what it certifies is not a snapshot of controls but a system, an Information Security Management System (ISMS). The mandatory backbone lives in clauses 4 to 10: define scope, assess risk, treat that risk, measure, and improve. The famous control list, Annex A of the 2022 revision, holds 93 controls across four themes (organizational, people, physical and technological), trimmed and restructured down from the 114 controls of the 2013 version. Crucially, you do not implement all 93 by default; you select the ones your risk assessment justifies and document the rest in a Statement of Applicability. Where this points you: if your buyers are international or enterprise, ISO 27001 travels further than SOC 2 and is publicly verifiable, which is why it shows up in RFPs. But you cannot fake the management system, auditors return year after year, so build the risk-assessment habit first and let the certificate follow.

SOC 2 is a report an auditor writes about you. ISO 27001 is a certificate that you run security as a system. PCI is a rulebook you don't get to opt out of.

PCI DSS is the odd one out, because it is not optional and it is not really "yours." The Payment Card Industry Data Security Standard is set by the PCI Security Standards Council, the body founded by Visa, Mastercard, American Express, Discover and JCB, and enforced through your acquiring bank and the card brands. The current version, v4.0.1, organises 12 requirements under six goals, and as of 31 March 2025 every applicable requirement, including the controls that were "future-dated" best practices when v4.0 first landed, is in full force. It applies to anyone who stores, processes or transmits cardholder data, and anyone connected to systems that do. The lever here is scope: the cheapest PCI programme is the one with the smallest footprint. Before you spend on controls, work out how to handle less card data, tokenisation, a compliant payment processor, redirecting the actual card entry off your systems, because every system that touches a card number drags itself into scope.

flowchart TD
  Q(["What is the buyer
actually asking for?"]) --> A{"Do you touch
payment-card data?"}
  A -->|"Yes"| P(["PCI DSS, mandatory.
Shrink scope first"])
  A -->|"No / handled by a processor"| B{"Who is the audience?"}
  B -->|"US B2B software buyers"| S(["SOC 2, CPA report,
pick the trust categories"])
  B -->|"International / enterprise RFPs"| I(["ISO 27001, certify the
management system"])
  S -.-> C(["Shared control core:
access, risk, monitoring, vendors"])
  I -.-> C
  P -.-> C
Different requests, mostly the same underlying work, the frameworks diverge on audience and proof, not on the security fundamentals. Leaders Loop

Why they overlap, and the trap of treating them separately

Here is the insight that saves teams the most pain: the three frameworks share a large common core. Access control, change management, vulnerability management, logging and monitoring, vendor risk, encryption, incident response, these show up in SOC 2's criteria, ISO 27001's Annex A, and PCI's twelve requirements alike, because they are simply what competent security looks like. The frameworks differ mostly in who attests to it and how it's packaged, not in the work itself. This is why SOC 2 and ISO 27001 are routinely pursued together.

So the failure mode is running three sequential projects, each with its own spreadsheet, its own consultant and its own panicked fortnight before the auditor arrives. Invert it: build one control set, anchored on a single risk assessment, and treat SOC 2, ISO 27001 and PCI as three reports you generate from it. Map controls once, collect evidence once, and let the frameworks be outputs rather than separate workstreams.

An honest limitation, the one every security leader knows and few say to the buyer. A clean report is not the same as being secure. SOC 2 and ISO 27001 tell you that controls were designed and (for a Type II or a mature ISMS) operated over a window, they do not promise you won't be breached, and plenty of the past decade's notable breaches hit certified, attested companies. PCI compliance is measured at a point in time and can lapse the day after the assessor leaves. The frameworks are a floor and a forcing function, not a guarantee. Treat the certificate as evidence of discipline, and keep doing the security work the report doesn't see, threat modelling, patching, the unglamorous habits between audits.

flowchart LR
  R(["One risk assessment
+ shared control set"]) --> M(["Map controls
once, to each framework"])
  M --> S(["SOC 2 report
(CPA attestation)"])
  M --> I(["ISO 27001 certificate
(accredited body)"])
  M --> P(["PCI evidence
(if in scope)"])
One programme, three outputs, the controls overlap, so the smart play is to build once and report many. Leaders Loop

A worked example

Take a forty-person B2B software company, call it Meridian, selling a scheduling tool to mid-market firms. (Illustrative scenario; not a real company.) Three demands land in the same quarter: a US enterprise prospect won't sign without a SOC 2 Type II, a European buyer's procurement team asks for "your ISO 27001," and because Meridian recently added in-app payments, its bank flags PCI. The instinct is panic and three parallel projects. The better instinct is to ask what each request is really for.

First, scope. Meridian's founder realises the payments were handled by a hosted checkout from a compliant processor, the card number never lands on Meridian's servers. That shrinks PCI from a frightening rebuild to a short self-assessment questionnaire, the lightest path available. Lesson one: reducing what you touch beats hardening what you touch.

Next, sequence. Rather than chase the SOC 2 and the ISO certificate as separate sprints, Meridian's head of engineering runs a single risk assessment, stands up one control set, access reviews, logging, change management, vendor checks, an incident-response runbook, and maps it to both frameworks. For SOC 2 they scope in security and availability only (their buyers care about uptime, not the optional privacy or processing-integrity categories), and commit to a Type II observation window rather than a hollow Type I. The same evidence, access logs, change tickets, the risk register, feeds the ISO 27001 ISMS. One body of work, two reports, plus the easy PCI questionnaire. The enterprise deal closes on the Type II; the European buyer gets a certificate they can verify publicly.

Frequently asked questions

Is SOC 2 a certification?

No, and the distinction matters when you describe it to customers. SOC 2 is an attestation: a licensed CPA firm examines your controls and issues a report stating their opinion. You don't "pass" or get certified; you receive a report (with an unqualified opinion if things went well). ISO 27001, by contrast, is a genuine certification issued by an accredited certification body. Calling a SOC 2 a "certification" in a contract is a small but common error.

SOC 2 or ISO 27001, which should we do first?

Follow your buyers. If your customers are mostly US-based software companies, they'll usually ask for SOC 2, so start there. If you sell internationally or into large enterprises and government, ISO 27001 is more widely recognised and, unlike a SOC 2 report, which is typically shared only under NDA, its certificate is publicly verifiable. Many companies eventually hold both, and because the controls overlap heavily, the second is far cheaper than the first.

Do we need PCI DSS if we use Stripe or a similar processor?

Almost certainly yes, but the scope can be tiny. Using a compliant processor and keeping card data off your own systems (for example, via a hosted payment page or tokenisation) usually lets you validate with a short self-assessment questionnaire rather than a full assessment. You don't escape PCI by outsourcing payments, but you can shrink it dramatically. Confirm your specific obligation with your acquiring bank or qualified assessor, as it depends on how you integrate.

Does any of this mean we're actually secure?

It means an independent party found your controls were designed, and (for a Type II or a mature ISMS) operating, over a defined window. That is real and worth having, but it is a floor, not a guarantee. Compliance is a point-in-time or period-in-time measurement; security is a daily practice. The frameworks force good habits and give buyers evidence of discipline; they don't replace threat modelling, patching, or the work between audits.

How long and how expensive is this?

It varies widely by company size, scope and how mature your controls already are, so treat any single number with suspicion. The honest planning answer: a first SOC 2 Type II or ISO 27001 certification is typically a multi-month effort because both require an observation period, not a one-week scramble. The cost driver you control most is scope, fewer systems, fewer trust categories, less card data in your environment. Get scope right before you get quotes.

Related in the Toolkit

Compliance frameworks only certify the security work underneath them, so the fundamentals (security fundamentals & threat modelling) are what actually keep you safe between audits, and the single most-audited control area is who can reach what (identity & access management).

Where to go next