SOC 1 vs SOC 2 vs SOC 3: Which Report Does Your Client Actually Want?

These three reports aren’t tiers of the same thing, and the numbering doesn’t indicate rank — SOC 3 isn’t “more advanced” than SOC 2, and you don’t need a SOC 1 before pursuing a SOC 2. SOC 1 evaluates controls relevant to your client’s financial reporting. SOC 2 evaluates your security and data-handling practices. SOC 3 isn’t an independent report at all — it’s a public-facing summary built from your SOC 2 results. Most SaaS and technology companies need SOC 2. A smaller subset also needs SOC 1. Almost nobody needs to “choose” SOC 3 on its own, because you can’t get one without first completing a SOC 2.

If a client tells you they need “a SOC report” without specifying which one, the rest of this guide tells you exactly which questions to ask to find out.

The Single Biggest Misconception About SOC Reports

The numbers 1, 2, and 3 make these sound like a progression — like SOC 3 is the advanced version of SOC 2, the way a CMMC Level 2 is more advanced than Level 1. That’s not what’s happening here. SOC 1 and SOC 2 answer completely different questions for completely different audiences, and SOC 3 isn’t a separate framework at all — it’s a packaging decision about an existing SOC 2.

Once that’s clear, the actual decision tree becomes much simpler. There are really only two questions that matter: does your service affect your client’s financial statements (that’s SOC 1 territory), and does your service involve handling their data securely (that’s SOC 2 territory)? SOC 3 only enters the conversation after you’ve already answered the SOC 2 question.

SOC 1 — Internal Control Over Financial Reporting (ICFR)

What it actually evaluates: SOC 1 examines controls at your organization that are likely to be relevant to user entities’ internal control over financial reporting — meaning, does your service touch anything that ends up on your client’s financial statements? 

Who actually needs this: Payroll service providers, billing platforms, fund administrators, and transaction processing companies are the classic examples. If a company outsources something that touches its financial statements, like payroll processing or transaction reconciliation, the company’s auditors need to know those outsourced processes have proper controls in place — and SOC 1 is how the service provider demonstrates that. 

Who reads it: SOC 1 reports are specifically intended to meet the needs of entities that use service organizations (user entities) and the CPAs that audit those user entities’ financial statements (user auditors) — in other words, your client’s finance team and their external auditors, not their IT or security team.

The control objectives are custom, not standardized: This is a critical and frequently misunderstood difference. SOC 1 control objectives are custom to your business and tailored around your specific financial processes, unlike SOC 2, where every audit evaluates your implementation against the same standardized Trust Services Criteria framework, even if the underlying controls vary. There’s no universal SOC 1 checklist — you and your auditor define the relevant control objectives together based on what your service actually does.

The standard behind it: SOC 1 reports are issued under SSAE 18 (Statement on Standards for Attestation Engagements No. 18), specifically AT-C Section 320 — a different section of the standard than the one governing SOC 2.

A frequent point of confusion worth flagging directly: some organizations and even some auditors mistakenly request SOC 1 despite having no direct applicability to ICFR. If your service doesn’t touch your client’s financial statements — you’re not processing payments, payroll, or anything that appears as a line item in their books — SOC 1 isn’t the right report, no matter what the request says. This is one of the more common, and more expensive, missteps in this whole space.

SOC 2 — Security and Data Management Controls

What it actually evaluates: SOC 2 assesses your organization’s controls against the AICPA’s Trust Services Criteria: security, availability, processing integrity, confidentiality, and privacy. SOC 2 is about security — “How does this vendor protect our data?” is the key question, and it’s built for IT and security teams, not finance.

Who actually needs this: This is the report most SaaS, cloud, and technology companies are asked for. Enterprise procurement teams, investors, and security-conscious buyers request SOC 2 specifically because it speaks directly to how you handle their data.

Standardized, not custom: Unlike SOC 1, SOC 2 control objectives are standardized — every audit evaluates your implementation against the same Trust Services Criteria framework, even though the specific controls you use to meet that framework can vary by organization.

The standard behind it: SOC 2 falls under SSAE 18, AT-C Sections 105 and 205 — different sections than SOC 1’s AT-C 320.

Restricted distribution: A SOC 2 report is a restricted-use report — it’s not public, and it’s typically shared under NDA with customers, partners, or regulators who specifically request it, because it contains detailed information about your internal systems and controls that you don’t want broadly circulating. 

This is the report covered extensively elsewhere on this site — see our full breakdown of SOC 2 Type I vs. Type II if this is the report you’re evaluating.

SOC 3 — The Public Summary, Not a Separate Framework

What it actually is: This is the piece that surprises people most. SOC 3 is not an independently earned report — a SOC 2 report must be written in order to prepare a SOC 3 report. Think of SOC 3 as a high-level, “redacted” version of your SOC 2 Type II report — same underlying audit, same Trust Services Criteria, far less detail. 

What gets removed: A SOC 3 includes management’s assertion and the auditor’s opinion, but it does not contain the specific controls that were tested or the detailed results of that testing — the parts of a SOC 2 that a security team would actually scrutinize during due diligence. 

Why it exists at all: SOC 2 reports are private and typically shared only with customers and prospects under NDA, whereas SOC 3 reports don’t contain confidential information or the same level of detail, so they can be released publicly as marketing material. If you want a security-posture asset you can post on your website or hand to anyone without an NDA, that’s what SOC 3 is for. 

Type II only — there’s no SOC 3 Type I: SOC 3 reports are issued only in Type II format, since a point-in-time snapshot (Type I) isn’t considered meaningful enough to publish broadly. If you haven’t completed a SOC 2 Type II observation period, you can’t get a SOC 3 yet, regardless of how clean your Type I looked. 

Cost reality: Because the underlying audit work is nearly identical to a SOC 2, the cost of adding a SOC 3 is typically much smaller than a standalone audit — if you’re already pursuing SOC 2, you can often request a SOC 3 from the same auditor for a small added fee rather than as a separate, expensive engagement.

The honest limitation: A SOC 3 is useful in demonstrating that you’ve engaged a third-party firm to help your organization achieve SOC compliance, but a client or prospect conducting thorough due diligence will require a SOC 2 with supporting documentation to actually gain the level of comfort and understanding they need. Don’t let a SOC 3 be your only artifact if a sophisticated enterprise buyer is asking real security questions — it’s a complement to SOC 2, not a substitute for it. 

 Side-by-Side Comparison

How to Actually Figure Out What Your Client Wants

When a client says “we need a SOC report” without specifying which one, ask these questions in order:

1. “Does our service affect your financial statements or financial processes?”
If yes — you’re processing payments, handling payroll, managing transactions that flow into their books — SOC 1 is likely the right answer, or at minimum part of the conversation.

2. “Is your security or IT team the one requesting this, or is it finance?”
Security and IT teams almost always want SOC 2. Finance teams or external auditors reviewing financial statements are the ones who actually need SOC 1.

3. “Do you need the detailed report, or just a public-facing assurance?”
If they want something they can review in depth as part of vendor due diligence, that’s SOC 2. If they just want public confirmation that you’ve been independently assessed — often for a quick procurement checklist rather than deep review — SOC 3 may be sufficient, but remember it only exists as a companion to SOC 2, not a replacement for it.

4. “Could you need more than one?”
It’s entirely possible to need both SOC 1 and SOC 2 — a billing platform that also stores customer data is a common example. Start with the report your customers prioritize first, then consider adding the other based on demand rather than pursuing both simultaneously without a clear driver. 

Imagine a SaaS company that processes subscription billing and also stores customer usage data. Their enterprise client’s security team asks for “a SOC report” during procurement. Without clarifying, the company might assume SOC 2 is sufficient — and for the security review, it is. But if that same client’s finance team is separately evaluating whether this vendor’s billing errors could create discrepancies in their own financial statements, that’s a SOC 1 conversation, with a different audience and a different report entirely.

This is exactly the kind of situation where asking the four questions above — rather than assuming “SOC report” means SOC 2 by default — saves a company from scoping the wrong engagement.

Not sure which SOC report your client actually needs — or whether you need more than one? We’ll help you figure out the right scope before you commit budget to the wrong engagement.

FAQ SECTION

Q: Do I need a SOC 1 before I can get a SOC 2?
A: No. The numbers don’t indicate a sequence or a hierarchy of standards — SOC 1, 2, and 3 are simply different reporting types, and you can pursue SOC 2 without ever needing a SOC 1.

Q: Is SOC 3 better than SOC 2, since it’s a higher number?
A: No. The numbering doesn’t indicate a particular sequence or a higher set of standards — and in fact, a SOC 2 report must be completed before a SOC 3 can even be issued, since SOC 3 is a public summary of SOC 2, not an independent report. 

Q: Can I get a SOC 3 without doing a SOC 2 first?
A: No. A SOC 2 report must be written in order to prepare a SOC 3 report — there’s no standalone SOC 3 audit path. 

Q: My client asked for “a SOC report.” How do I know which one they mean?
A: Ask whether the request is coming from their finance/audit team (likely SOC 1, if your service affects their financial reporting) or their security/IT/procurement team (likely SOC 2). If they just want a public-facing assurance document rather than detailed due diligence material, SOC 3 may be appropriate as a companion to an existing SOC 2.

Q: Is a SOC 3 enough for enterprise due diligence?
A: Usually not on its own. A SOC 3 demonstrates that you’ve engaged a third-party firm for SOC compliance, but a client conducting thorough due diligence will typically require the detailed SOC 2 report to gain real comfort with your control environment. 

Q: Can a company need both SOC 1 and SOC 2?
A: Yes. This is common when a service impacts both financial systems and sensitive data — for example, a billing platform that also stores customer data. Most companies start with whichever report their customers are actively requesting, then add the other if demand emerges.