The fastest way to settle the SOC 1 vs SOC 2 question is to look at who is asking. If the request came from a prospect’s security team, a vendor risk questionnaire, or a procurement portal, they want a SOC 2. If it came from your customer’s finance team, or was forwarded from their external financial statement auditor, they want a SOC 1.
That is not a rule of thumb about job titles. It reflects what the two reports are for. A SOC 1 reports on controls at your organization that are relevant to your customers’ internal control over financial reporting — ICFR. A SOC 2 reports on controls relevant to security, availability, processing integrity, confidentiality or privacy, measured against the AICPA trust services criteria. They are different examinations with different subject matter, and one does not substitute for the other.
What a SOC 1 is actually about
Your customer — the user entity — has financial statements. Those financial statements get audited. If your service processes transactions or holds data that flows into their numbers, then part of their internal control over financial reporting sits inside your company, where their auditor cannot see it.
The SOC 1 report solves that. It gives the user auditor an independent view of the controls at your organization that could affect their client’s financial statements, so they can decide how much reliance to place on them and what else they need to test.
Critically, a SOC 1 is not measured against a standard checklist. You define the control objectives, based on what your service does and what could go wrong from the user entity’s financial reporting perspective. A payroll processor’s objectives will concern completeness and accuracy of payroll calculations, authorization of pay changes, and timely remittance. A loan servicer’s will concern payment application, interest calculation and account balances.
Your auditor then examines whether those objectives are stated fairly, whether controls were suitably designed to achieve them, and — in a Type 2 — whether they operated effectively over a period.
What a SOC 2 is actually about
A SOC 2 is measured against a defined framework: the AICPA trust services criteria. Security is always included. Availability, Processing Integrity, Confidentiality and Privacy are added when your commitments or your buyers’ expectations call for them.
The audience is different too. A SOC 2 goes to customers, prospects, and their security and risk functions — people deciding whether it is safe to put data or an important workflow into your platform. They are asking about access control, change management, encryption, monitoring, incident response and vendor management, not about whether your outputs are complete and accurate enough for a balance sheet.
The comparison in one table
| SOC 1 | SOC 2 | |
|---|---|---|
| Subject matter | Controls relevant to user entities’ internal control over financial reporting | Controls relevant to the trust services criteria |
| Measured against | Control objectives you define | AICPA trust services criteria (Security plus any of four others) |
| Who asks for it | Your customer’s finance team or their financial statement auditor | Your customer’s security, risk or procurement team |
| Who reads it | The user auditor, primarily | Security reviewers, risk teams, sometimes customers directly |
| Type 1 / Type 2 | Both exist | Both exist |
| Typical trigger | Your customer is being audited and you are in scope | A deal is blocked pending a security review |
Note the last row. The two reports usually arrive in your life through completely different doors, which is why the “who asked” test works so well.
The overlap, and why it is smaller than it looks
Both reports will look at logical access, change management and IT operations, and both will ask about the same underlying systems. That is real overlap and it is why organizations that need both usually run them together with a shared evidence effort.
But the reason those areas are examined differs, and so does the depth. In a SOC 1, access controls matter because an unauthorized change to a transaction processing rule could misstate a customer’s financials. In a SOC 2, access controls matter in their own right, and the criteria go into areas — vendor management, security awareness, incident communication, risk assessment — that a SOC 1 may barely touch.
Meanwhile a SOC 1 goes somewhere a SOC 2 usually does not: the transaction processing itself. Completeness and accuracy of the calculation, authorization of the input, handling of rejected items, reconciliation of what came in against what went out. These are financial reporting risks and they will not be in your SOC 2 unless you scoped Processing Integrity, and even then the framing differs.
So: a SOC 2 does not satisfy a user auditor asking about ICFR, and a SOC 1 does not satisfy a security reviewer asking whether your infrastructure is hardened.
Do you need both?
Some organizations genuinely do. Payment processors, payroll and benefits administrators, claims processors, loan servicers, treasury and billing platforms, and BPOs handling accounting functions are the common cases — they touch their customers’ numbers and their customers’ data.
If both apply, do not run them as two unrelated projects. Practice varies, but a shared approach usually means one system description effort where the scope overlaps, one evidence collection cycle, aligned observation periods so you are not sampling twice, and one set of walkthroughs for the shared IT general controls. Firms differ in how far they combine the fieldwork; ask before you engage.
If only one applies — and for most SaaS companies that is the SOC 2 — do not add the other speculatively. A SOC 1 with control objectives nobody asked for is an expense with no audience.
What about SOC 3?
SOC 3 is a short, general-use report based on the same trust services criteria examination as a SOC 2. It contains the opinion and a system overview, but not the detailed description of controls or the tests and results.
Because it is general use, you can put it on your website. Because it lacks the detail, it will not satisfy a serious security review. Teams usually issue a SOC 3 alongside a SOC 2 as a public-facing artifact, not instead of one. There is no SOC 3 equivalent for SOC 1.
What to do next
Go back to the person who asked and get one specific answer: are they asking because of a security or vendor risk review, or because of a financial statement audit? If it is the second, ask whether the request originated with their external auditor, and if so, ask which of your services that auditor considers in scope.
That last question is the one most people skip, and it determines your control objectives. Assurion is a licensed CPA firm and performs both SOC 1 and SOC 2 examinations; if you are getting mixed signals from different people at the same customer, that is worth untangling before you scope anything.