SOC 1 vs SOC 2: which report your buyer is actually asking for

Two emails land in the same week. One is from a prospect's CISO asking for your SOC 2 Type II. The other is from a different prospect's external auditor asking for your SOC 1. You have budget for one engagement this year. Which one answers the question in front of you?

Short answer first, then the mechanics.

The one-sentence answer

A SOC 1 opines on controls relevant to your customers' internal control over financial reporting. A SOC 2 opines on controls relevant to security, availability, processing integrity, confidentiality, and privacy. Finance teams ask for SOC 1. Security teams ask for SOC 2. They are not substitutes. Both sit inside the AICPA's SOC for Service Organizations suite, alongside SOC 3.

What SOC 1 covers

SOC 1 is scoped to ICFR. If your service calculates, holds, or moves numbers that end up on somebody else's income statement, balance sheet, or cash-flow statement, your customers' auditors need comfort that your controls work. A SOC 1 is how they get it without sending their own team to inspect you.

The control objectives in a SOC 1 read like "Controls provide reasonable assurance that payroll disbursements are calculated in accordance with authorized pay rates and approved hours." The pillar post, what is a SOC 1 report, walks through the five sections of the report and the Complementary User Entity Controls that show up in every one.

What SOC 2 covers

SOC 2 is scoped to the Trust Services Criteria: Security (always), and optionally Availability, Processing Integrity, Confidentiality, and Privacy. The report answers the question an enterprise procurement team is trying to answer about you as a vendor, which is whether customer data is safe in your systems.

The control objectives in a SOC 2 read like "Controls provide reasonable assurance that logical access to production systems is restricted to authorized personnel." The pillar primer is what is SOC 2 compliance.

Both reports share the same document shape. Both are attestations issued by a licensed CPA firm under AICPA attestation standards — specifically SSAE No. 18, which recodified the attestation literature that governs SOC 1 and SOC 2 alike. The scoping rules diverge (SOC 1 points at the SOC 1 ICFR guidance; SOC 2 points at the Trust Services Criteria), but the fieldwork mechanics rhyme. The control libraries overlap on the infrastructure layer and diverge everywhere else.

Who asks for each

The requester is the cleanest signal.

SOC 1 requesters are almost always on the finance side: your customer's controller, their CFO's office, or the external audit firm signing their financial statements. The request often arrives close to their fiscal year-end, which is not a coincidence. If the customer is a public filer, the user auditor is typically a PCAOB-registered firm and the request is not optional.

SOC 2 requesters are on the security side: vendor risk, procurement, the CISO's team, or an outside security questionnaire platform acting on their behalf. The request usually arrives mid-sales-cycle, right after the deal gets routed to vendor review. Our piece on what a SOC 2 report actually tells your buyer covers what they actually read when the PDF lands.

If you are not sure which request you are holding, look at the sender's title. Finance or audit means SOC 1. Security, IT, or procurement means SOC 2.

When you need both

Plenty of our clients run both programs. The common pattern: a product that touches customer money and stores customer data.

• Fintech platforms. Balances, ledgers, and transactions on the SOC 1 side; authentication, encryption, and availability on the SOC 2 side.
• Payroll and PEO platforms. Wage calculation and tax remittance on the SOC 1 side; employee PII and access management on the SOC 2 side.
• Outsourced accounting and fund administration. General ledger and reconciliation on the SOC 1 side; document confidentiality and infrastructure security on the SOC 2 side.
• Billing and revenue-recognition SaaS. Invoice generation and cash-receipt capture on the SOC 1 side; application security and availability on the SOC 2 side.

If you sell into procurement committees that include both a controller and a CISO, plan for both reports. The infrastructure controls (access, change management, backups, incident response) are shared. The business-process controls diverge.

A brief note on SOC 3

SOC 3 is the public-facing version of a SOC 2. Same auditor, same criteria, same testing, but the deliverable is a short, unrestricted-use report you can publish on your website or hand to a prospect without an NDA. It does not include the detailed system description or the control tables from Sections 3 and 4 of the SOC 2, which is the point: it proves you have a clean SOC 2 without leaking the control inventory.

Most companies treat SOC 3 as an add-on generated from an existing SOC 2 Type II, not a separate engagement. Full walkthrough in SOC 3 reports.

SOC 3 only exists on the SOC 2 side. There is no SOC 1 public-use equivalent, because the financial-reporting audience does not exist in a marketing-page context.

A SOC 2 wins the procurement review. A SOC 1 keeps your customer's 10-K from slipping.

How to sequence the two

For most SaaS, the order is SOC 2 first. The request arrives earlier in the sales cycle, the audience is wider, and a SOC 2 unblocks more revenue per dollar of audit fee. Type I or Type II is a separate decision inside that program.

Run SOC 1 when a specific customer's auditor explicitly asks for it, or when you can see the ask coming because your product sits inside the financial reporting chain. If your buyer is a PCAOB-audited filer, the ask is coming. The mirror-image Type 1 vs Type 2 decision on the SOC 1 side lives in SOC 1 Type 1 vs Type 2.

Shipping a SOC 1 before any customer has asked is a reasonable bet only if your entire go-to-market is finance-integrated products sold into enterprise finance teams. Otherwise the SOC 2 earns its keep first.

Cost and timeline, side by side

The engagements are similar in order of magnitude. Honest ranges, for a growth-stage SaaS with one product:

• SOC 1 Type 2 or SOC 2 Type II, first year from a standing start: nine to fourteen months. Three to four months of readiness, six to twelve months of observation window running in parallel with evidence collection, one to two months of fieldwork, six to ten weeks of reporting.
• Annual renewal in steady state: roughly twelve months end to end per report, timed so the report lands shortly after the observation window closes.
• Audit fees: roughly $25k to $60k per year per report, depending on scope, criteria, and firm. Readiness is usually the larger first-year line item.

If you need both, a combined engagement is noticeably cheaper than two separate ones. Shared planning, shared infrastructure testing, one evidence request list, one fieldwork window. Done once, two reports is roughly one and a third audits, not two. Done as two separate projects by two separate firms, it is close to two audits plus duplicative evidence work and a tired team.

The sequencing question is not "which report is better." It is "which report unblocks the revenue sitting in front of me, and what is the cheapest way to get the second one ready before the next request lands."

---

If you are staring at a prospect's email asking for "the SOC" and it is not obvious which one they mean, get in touch or see the services we offer. We will help you read the request, scope the right engagement, and plan the second report before the next deal pauses on it.