SOC 1 vs SOC 2 vs SOC 3: Which Report Do You Need?
SOC 1, SOC 2, and SOC 3 cover completely different territory. Here's what separates them and which one your customers are actually asking for.
The email from a prospective client's procurement team read: "Please provide your current SOC report." The founder who forwarded it to me had already called two auditors. One quoted a SOC 2 engagement. The other quoted SOC 1. Nobody had explained that these aren't competing bids on the same thing; they're fundamentally different reports that prove different things to different audiences.
That conversation happens constantly. The three SOC reports share a name family and they all come from the same standards body, so people assume they're versions of the same thing. They're not. Getting this wrong means spending months on the wrong audit and still failing to satisfy the customer who asked.
What "SOC" actually stands for
All three reports come from the AICPA, the same organization that governs financial audits in the United States. SOC stands for Service Organization Control. The framework exists because companies increasingly depend on outside vendors who touch their data, their systems, or their financial transactions. When a financial auditor is examining a company's books, they need to know whether the payroll vendor or the cloud ERP provider that company relies on has real controls in place. SOC reports are how service organizations prove that to their clients' auditors and security teams.
The reports share that lineage. What varies is the type of controls being examined and who the intended reader is.
SOC 1: it's about financial reporting, not data security
SOC 1 gets mislabeled constantly as a less advanced version of SOC 2. It isn't a predecessor or a lighter alternative; it covers an entirely different risk category. A SOC 1 report addresses internal control over financial reporting (ICFR). The question it answers is whether this service organization's control environment affects the accuracy of its clients' financial statements.
That makes SOC 1 relevant to a specific subset of service organizations. If your product directly touches the financial transaction flows or reporting infrastructure of your clients, their external auditors may require a SOC 1 as part of their own audit work. Common examples include:
- Payroll processors
- Fund administrators for investment firms and hedge funds
- Outsourced accounts payable or receivable providers
- Benefits administration platforms that affect payroll reporting
- Data centers hosting financial transaction systems
This is a narrower category than most people expect. If you're a typical SaaS company storing customer records, managing projects, or running marketing automation, none of that touches your clients' financial reporting. SOC 1 is not your report.
Like SOC 2, SOC 1 comes in two types. Type I examines whether your controls are suitably designed on a given date. Type II covers an observation period, usually six to twelve months, and tests whether controls operated effectively throughout. In practice, clients' auditors almost always need Type II because a point-in-time snapshot doesn't satisfy the requirements of a full financial audit engagement.
The scope of a SOC 1 isn't defined by a fixed framework the way SOC 2 uses the Trust Services Criteria. Instead, the service auditor identifies which controls are relevant to the user entities' financial reporting and tests those specifically. That means the scoping conversation is more iterative and depends heavily on what your clients actually need from you.
SOC 2: the one most tech companies need
SOC 2 is built around the AICPA's Trust Services Criteria, which assess five categories of control: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security (sometimes called the Common Criteria) is the only mandatory one. Most companies start there and add others based on what their customers require. Availability is common for infrastructure products. Privacy comes up when health or consumer data is in scope.
The full picture is in the SOC 2 guide, but the thing worth emphasizing here: a SOC 2 report is not a certification. There is no central registry of certified companies. What you get is a written opinion from a licensed CPA firm saying your controls were real and working. You share that report with customers under NDA when they ask for it in their vendor review process.
SOC 2 also comes in Type 1 and Type 2. Type 1 checks whether your controls are designed correctly on a given date. Type 2 tests whether they operated effectively over a period, typically three to twelve months. The difference matters because enterprise buyers, particularly the ones with real third-party risk programs, generally won't accept a Type 1 as final assurance. Type 2 is the document that actually closes deals.
SOC 3: what it is and what it isn't
SOC 3 is the report that confuses people most, because the name implies it's the next step after SOC 2. It's not. SOC 3 is a publicly distributable summary of the same examination that produces a SOC 2. The auditor runs the same tests and reaches the same conclusions, but the SOC 3 report strips out the detailed control descriptions and is written for general distribution rather than restricted use.
That restriction matters. A SOC 2 report contains specific details about your control environment: what you test, how often, what your thresholds are. You share it under NDA because a careful reader gets real information about your security posture. For a customer's security team doing vendor risk assessment, that detail is exactly what they need.
SOC 3 drops all of that. What you get is a short report with a seal saying the auditor examined your controls and found them effective, without specifying what those controls are. It's suitable for posting publicly, and many companies put it on their trust page. But it won't satisfy a security team doing a serious review. They'll ask for the SOC 2 regardless of whether you have a SOC 3 displayed.
The practical use of SOC 3 is as a trust signal. Posting it on your trust page tells prospects you've been audited without revealing anything meaningful about how. It does not replace sharing the SOC 2 in procurement. If you already have a SOC 2, you can usually obtain a corresponding SOC 3 from the same audit firm at modest additional cost. There's no reason to pursue SOC 3 before you have SOC 2.
Which one you actually need
The decision mostly makes itself once you understand what each report covers.
Get SOC 2 if you're a B2B SaaS company, a cloud services provider, or any service organization that stores, processes, or transmits customer data. This covers the overwhelming majority of tech companies and is what North American enterprise buyers expect to receive in a vendor security review.
Get SOC 1 if your service directly affects your clients' financial reporting: payroll, fund administration, transaction processing, outsourced accounting. The clearest indicator is when a client's external auditors explicitly request it as part of their own audit engagement. That request, from a CPA firm, is unambiguous.
Add SOC 3 only after you have SOC 2, and only if public trust-page signaling is worth the marginal cost.
Consider both SOC 1 and SOC 2 if your product crosses the boundary. A payroll platform that also stores sensitive HR records is one example. The financial auditors need the SOC 1; the security reviewers need the SOC 2. They're separate engagements with separate control populations, so carrying both means running two audits. That's a real cost, but sometimes unavoidable.
When in doubt, ask the requester to be specific: which report does your team need, and is this for a security review or for your external auditors? A security analyst asking about controls wants SOC 2. A financial auditor asking about ICFR wants SOC 1. They usually know which they mean. The ambiguity tends to live on the vendor side, not the customer side.
Before you choose an auditor
One mistake I see frequently: companies engage an audit firm before confirming which report their largest customers actually need. That matters because SOC 1 and SOC 2 use different standards, different control frameworks, and different evidence collections. Three months spent building SOC 2 controls is wasted effort if you needed SOC 1.
Talk to your largest customer and ask their procurement or finance team which report satisfies their requirements. If you're building toward SOC 2, run your program against the readiness checklist before paying a deposit to a CPA firm. It takes a few hours and will tell you where the gaps are before an auditor starts charging by the hour to find the same things.