A SOC report is a document produced by an independent CPA firm after it examines a company's internal controls and states, in writing, whether those controls are designed properly and — in some cases — whether they actually worked over a period of time. SOC stands for System and Organization Controls, and the report is the deliverable of what's called a SOC audit. If you're a SaaS founder and an enterprise prospect's security team just emailed asking for "your SOC report," this is the thing they mean — and which flavor of it they want depends on what your product actually does for them.
That last part is where most of the confusion starts. There isn't one SOC report. There are three, they answer different questions, and only one of them is relevant to the vast majority of SaaS companies. Here's how to tell them apart without wading through accounting standards.
What Is a SOC Report, in Plain Language
Strip away the acronyms and a SOC report is really just a letter from an auditor that says: "We looked at this company's controls, here's what we found, and here's our opinion on whether they're adequate." It's not a certificate, not a pass/fail badge, and not something a government agency issues. It's an attestation — a professional opinion, backed by evidence, produced under standards set by the American Institute of Certified Public Accountants (AICPA). The reason enterprise buyers trust it is the same reason they trust an audited financial statement: a third party with professional liability on the line looked at the claims and signed their name to an opinion about them. That's a meaningfully stronger signal than a vendor's own security page, which is why procurement teams ask for it instead of taking a company's word for it.
SOC 1 vs SOC 2 vs SOC 3
The three report types exist because they were built to answer three different questions for three different audiences. Here's the distinction that actually matters when you're trying to figure out which one someone is asking you for.
| Report | What it covers | Who typically needs it |
|---|---|---|
| SOC 1 | Controls relevant to a customer's financial reporting — e.g., does your system process transactions or billing data accurately? | Payroll processors, payment platforms, companies whose systems feed into a customer's financial statements |
| SOC 2 | Controls over security, availability, processing integrity, confidentiality, and privacy — the general security posture of the company | Most B2B SaaS companies; this is what enterprise security reviews are almost always asking for |
| SOC 3 | The same underlying controls as SOC 2, but summarized at a high level with no detailed testing results | Companies that want a public-facing document — a trust page or marketing asset — without disclosing the detailed SOC 2 report |
SOC 2 itself splits again into two sub-types, which is where a second layer of confusion usually sets in. A Type 1 report is a snapshot: it says your controls were designed correctly as of a specific date. A Type 2 report covers a window of time — typically six to twelve months — and says your controls actually operated consistently throughout that period, not just that they existed on paper. Enterprise buyers overwhelmingly prefer Type 2, because it answers the harder and more useful question. If you've already got a Type 1 and are wondering what changes next, the detail of that transition is covered in our guide on why enterprise clients request a SOC 2 report and what they're actually checking for once they have it.
Who Issues a SOC Report — and Who's Allowed to Read It
Only a licensed CPA firm can issue a SOC report. That's a hard requirement, not a convention — these are attestation engagements governed by AICPA standards, and a report from anyone else isn't a SOC report, no matter what it's titled. This is also why a SOC report is never free or instant: a real auditor has to examine real evidence and put their license behind the opinion. Who can read the finished report depends on the type. SOC 1 and SOC 2 reports are restricted-use documents — they're shared under NDA with existing or prospective customers and their auditors, not posted publicly. SOC 3 exists specifically to solve that problem: because it's a general-use summary with the sensitive detail stripped out, companies can publish it openly, often on a trust page, as a lightweight proof point before a deeper security review even starts.
Why "SOC Audit" and "SOC Report" Get Used Interchangeably
You'll see both terms used for what feels like the same thing, and in casual conversation that's close enough. Technically, the audit is the process — the auditor's examination of your controls, the evidence they review, the testing they perform — and the report is the output of that process, the document you actually hand to a customer. A founder might say "we're doing our SOC audit" to describe the months of work, and the same founder will later say "here's our SOC report" when attaching the PDF to an email. Both are correct; they're just describing different ends of the same engagement. The practical reason this matters: when a prospect's security team says "we need your SOC 2," they mean the report. When your team talks about timeline, cost, and what engineers need to do, you're talking about the audit. Keeping the two straight helps when you're explaining the project internally — to engineers who want to know what work is required, or to a board that wants to know what's being purchased. If that's the conversation ahead of you, our guide to explaining SOC 2 to your board or investors walks through exactly that framing.
Which One a SaaS Company Almost Always Needs
If you're running a B2B SaaS product and an enterprise prospect's security questionnaire mentions "SOC," it's SOC 2 they want, specifically Type 2, nearly every time. SOC 1 only applies if your system is doing something that feeds directly into a customer's financial statements — a payments processor or payroll platform, for instance. For a typical SaaS company storing and processing customer data, security and availability are the controls under scrutiny, which is exactly what SOC 2 was built to cover. A SOC 3 might come later, as a public trust-page asset once you already have a SOC 2 report to summarize — but it's a nice-to-have, not where you start. Within SOC 2, most companies begin with a Type 1 to get an initial report in enterprise buyers' hands faster, then start the Type 2 observation period immediately afterward so there's no gap between reports. The two sub-types aren't a choice between one or the other so much as a sequence most companies move through — Type 1 first, Type 2 close behind it, because that's the one procurement teams are ultimately going to ask for. Once you know it's SOC 2 you need, the next question is usually access control — it's the single area auditors scrutinize hardest and the one most early-stage teams have the most informal gaps in. Our practical guide to access control and least privilege is a reasonable next stop if that's where you're headed.
None of this requires you to become a compliance expert before you can have an intelligent conversation about it. Knowing that "SOC 2 Type 2" is the specific thing being asked for, that it comes from a licensed CPA firm, and that it's a report — not a software feature or a checkbox — is usually enough to walk into the next conversation, whether that's with a prospect's security team or your own board, without feeling like you're behind on vocabulary everyone else already knows.