The AICPA publishes a family of System and Organization Controls reports — SOC 1, SOC 2, and SOC 3 — and they are remarkably easy to confuse. They share a name and an auditor type, but they answer different questions for different audiences. Choosing the wrong one wastes time and budget, or produces a report that does not satisfy what a customer actually asked for.
This guide explains each report in depth, clarifies the Type 1 versus Type 2 distinction that sits inside SOC 1 and SOC 2, walks through how to choose, and covers the common situations where you may need more than one. By the end you will know exactly which report your buyers want and why.
The three reports at a glance
Each SOC report serves a distinct purpose and audience, and two of the three are restricted-use documents shared only under NDA.
- SOC 1 - controls relevant to a customer's financial reporting (ICFR); audience is customers' auditors and finance teams; restricted use
- SOC 2 - security and the Trust Services Criteria; audience is security and procurement teams; restricted use
- SOC 3 - a public, general-use summary of a SOC 2; audience is anyone; freely shareable
Here is how the three reports compare side by side:
| Aspect | SOC 1 | SOC 2 | SOC 3 |
|---|---|---|---|
| Focus | Controls over financial reporting (ICFR) | Security and the Trust Services Criteria | Public summary of a SOC 2 |
| Primary audience | Customers' auditors and finance teams | Security and procurement teams | Anyone (general public) |
| Use and sharing | Restricted - shared under NDA | Restricted - shared under NDA | General use - freely shareable |
| Based on | AICPA SSAE 18 (ICFR) | AICPA Trust Services Criteria | Same examination as SOC 2 |
| Type 1 and Type 2? | Yes - both available | Yes - both available | Type 2 basis only |
| Best for | Payroll, billing and other services affecting clients' financials | SaaS and tech companies handling customer data | Marketing and a public trust signal |
SOC 1: controls over financial reporting
A SOC 1 report addresses the controls at a service organization that could affect its customers' financial statements — internal control over financial reporting, or ICFR. It exists because when you outsource a function that flows into a client's books, that client's auditors need assurance over your controls. Classic SOC 1 candidates are payroll processors, billing and invoicing platforms, payment processors, and loan servicers.
SOC 1 is governed by SSAE 18 and is intended for a restricted audience: your customers and their financial auditors. It is not a security report — if a buyer is asking how you protect data, SOC 1 is the wrong answer.
Free resource
SOC 2 Readiness Kit
A practical checklist + policy starter pack to fast-track your audit.
SOC 2: security and the Trust Services Criteria
A SOC 2 report addresses controls mapped to the AICPA Trust Services Criteria: Security (always), plus optionally Availability, Processing Integrity, Confidentiality, and Privacy. It is the report the vast majority of SaaS, cloud, data, and technology companies need, and the one enterprise security teams request during vendor due diligence. Like SOC 1, it is restricted-use and shared under NDA, and it comes in Type 1 and Type 2 variants.
SOC 2 is the most detailed of the three: it includes the auditor's opinion, management's assertion, a full system description, and — for a Type 2 — the specific tests the auditor performed and their results. That depth is exactly why customers trust it and why it can replace lengthy security questionnaires.
SOC 3: the public trust summary
A SOC 3 report is a lightweight, general-use version of a SOC 2. It carries the auditor's opinion and a short system overview but deliberately omits the detailed system description and the control test results, so it contains nothing sensitive. That makes it safe to publish on your website, attach to sales decks, or hand to a prospect without an NDA.
Because a SOC 3 is generated from the same examination as your SOC 2, producing one is inexpensive. It is a marketing and trust asset, not a due-diligence document — sophisticated buyers will still ask for the full SOC 2 under NDA.
Type 1 vs Type 2 (inside SOC 1 and SOC 2)
Both SOC 1 and SOC 2 come in two types, and this is a separate axis from the report number. A Type 1 assesses whether controls are suitably designed at a single point in time; a Type 2 assesses whether those controls operated effectively across a period, typically three to twelve months. Type 2 provides far stronger assurance because it shows controls worked consistently, not just on paper, which is why enterprise buyers almost always want a Type 2. Knowing which report applies is an important first step toward SOC 2 compliance.
How to choose the right report
Let the customer's question and the nature of your service decide:
- Buyers ask how you secure and protect their data - you need SOC 2
- Your service affects customers' financial statements (payroll, billing, payments) - you need SOC 1
- You want a public trust asset to post or share freely - add a SOC 3 alongside your SOC 2
- You both process financial data and handle sensitive data - you may need both SOC 1 and SOC 2
For the large majority of technology companies, the answer is simply SOC 2 Type 2, with a SOC 3 as an optional public complement.
Why customers almost always ask for SOC 2
In B2B software, SOC 2 has become the default trust signal. When a security or procurement team evaluates a vendor, they want independent assurance that the vendor's controls protect data — exactly what SOC 2 attests to. A current SOC 2 Type 2 report short-circuits the security review, removing one of the most common deal-stalling blockers in enterprise sales. That is why, even when a customer vaguely asks for 'your SOC report,' they almost always mean SOC 2.
When you need more than one report
Some organizations genuinely need multiple reports. A payments or payroll platform often holds both a SOC 1 (because it affects clients' financials) and a SOC 2 (because it handles sensitive data and faces security due diligence). Many companies that produce a SOC 2 also issue a SOC 3 so they have something public to share. The reports can be produced by the same CPA firm, and the underlying controls overlap, so holding more than one is less duplicative than it sounds.
How the reports relate to other frameworks
SOC 2 is frequently compared to ISO 27001. SOC 2 is an attestation against the AICPA criteria performed by a CPA firm; ISO 27001 is a certification against an international standard issued by an accredited body. The underlying controls overlap heavily, so a mature SOC 2 program is a strong foundation for ISO 27001, HIPAA, or PCI DSS — map your controls once and satisfy several frameworks. SOC 1, by contrast, sits apart because it is about financial-reporting controls rather than security.
Common mistakes when choosing a SOC report
A handful of avoidable errors lead teams to build the wrong report or buy more than they need:
- Producing a SOC 1 when buyers actually wanted security assurance (SOC 2) - the two are not interchangeable
- Treating a SOC 3 as a substitute for SOC 2 in due diligence - it is a public summary, not the report enterprises review
- Starting with a Type 1 and stopping there when customers ultimately require a Type 2
- Over-scoping a SOC 2 with all five criteria before any contract requires them
- Assuming one report covers every customer - confirm which report and which criteria your contracts reference
The lowest-cost way to avoid these is a short scoping conversation before you commit, so you build exactly the report your buyers ask for and nothing you do not need.
How ISpectra helps you choose and execute
ISpectra starts by clarifying which report your buyers actually need — avoiding the costly mistake of building the wrong one — then prepares your program, coordinates an independent CPA firm, and can arrange SOC 2 and SOC 3 (and SOC 1 where relevant) from a single, well-managed engagement.
Free consultation
Need help with SOC 2?
Talk to our certified compliance team — we’ve supported 200+ audits.