SOC 1 vs SOC 2: which report do your customers actually need?
SOC 1 covers controls that touch your customers' financial reporting; SOC 2 covers security and the other Trust Services Criteria. Which one a customer asks for depends entirely on what you do for them.
Same audit family, two different questions
SOC 1 and SOC 2 are both System and Organization Controls reports issued by a licensed CPA firm under the AICPA's attestation standards (SSAE 18). The resemblance largely ends there. SOC 1 answers a financial question: do your controls affect the accuracy of your customers' financial statements, and can their auditors rely on them? SOC 2 answers a security and operations question: are the controls protecting customer data and systems suitably designed and operating effectively? Knowing which question a given customer is really asking is the fastest way to figure out which report you need.
SOC 1: controls over financial reporting (ICFR)
SOC 1 is scoped to controls relevant to user entities' internal control over financial reporting, and it is governed specifically by AT-C section 320 within SSAE 18. It exists because when you handle something that flows into your customers' books, their financial-statement auditors need assurance about your controls without auditing you directly. Classic SOC 1 candidates include payroll processors, payment and billing platforms, claims processors, loan servicers, and SaaS tools whose calculations land in the general ledger. Rather than the Trust Services Criteria, a SOC 1 is built around control objectives that you and your auditor define for the specific processes you perform, and the report typically lists complementary user entity controls (CUECs) that your customers must operate on their end for the system to work as intended.
SOC 2: security and the Trust Services Criteria
SOC 2 is scoped to the AICPA's Trust Services Criteria and is governed by AT-C sections 105 and 205. Every SOC 2 covers the Security category (the common criteria), and you can add Availability, Processing Integrity, Confidentiality, and Privacy depending on the commitments you make to customers. This is the report a security team or procurement function asks for during vendor due diligence, and it has become the default trust artifact for B2B SaaS in North America. Where SOC 1 cares whether your system could misstate a customer's revenue, SOC 2 cares whether you could leak, lose, or fail to protect their data.
Type 1 vs Type 2 applies to both
Both reports come in two flavors, and the distinction is identical across SOC 1 and SOC 2. A Type 1 evaluates whether controls are suitably designed as of a single point in time, which is faster to obtain and useful as a first milestone. A Type 2 evaluates whether those controls also operated effectively across an observation period, commonly three to twelve months, and includes the auditor's detailed tests and results. Most sophisticated customers ultimately want a Type 2, because a design-only opinion says nothing about whether the controls actually ran day to day. A Type 1 is best treated as a stepping stone toward a first Type 2 rather than a destination.
How to decide, and when you need both
Map it to what you do for the customer. If your service feeds their financial statements (transaction processing, payroll, billing, anything their CFO or external auditor cares about), you likely need SOC 1. If you store or process their non-financial data and their security or procurement team is the one asking, you need SOC 2. Plenty of companies legitimately need both: a payments platform, for example, will field SOC 1 requests from accounting-driven buyers and SOC 2 requests from security teams. The reports are not interchangeable, so a SOC 2 will not satisfy an auditor who needs ICFR assurance, and a SOC 1 will not close a security questionnaire. When in doubt, ask the requesting customer who needs the report and why, because the answer almost always tells you which one to pursue.