How do you tell whether a customer needs a SOC 1 or a SOC 2?

Ask who inside their organisation wants it. A request from a security or third-party risk team is almost always a SOC 2. A request that came through their controller, their finance team or their external audit firm, often near their year-end, is usually a SOC 1, because the real audience is the auditor of their financial statements.

Does a SOC 2 cover the same ground as a SOC 1?

No. They use different subject matter and different criteria. A SOC 1 addresses controls likely to be relevant to a customer's internal control over financial reporting; a SOC 2 reports against the trust services criteria for security, availability, processing integrity, confidentiality and privacy. Neither is a substitute for the other, however thorough it is.

Who actually reads a SOC 1 report?

The AICPA says SOC 1 reports are intended to meet the needs of the entities that use service organizations and the CPAs who audit those entities' financial statements. In practice, that second group does the close reading — your customer's external auditor, deciding what evidence your controls can contribute to their audit.

Do some companies need both reports?

Yes, and it is common for payroll, payments, billing and claims platforms. The two examinations have different criteria and produce separate reports, but much of the underlying evidence overlaps, particularly IT general controls such as access management and change management. Scope them together rather than sequentially if both are likely.

Can we publish our SOC 2 report on our website?

That is what a SOC 3 is for. The AICPA describes SOC 3 reports as addressing the same control areas as a SOC 2 without the same level of detail, which is why they are general use reports that can be freely distributed. Most companies keep the SOC 2 under NDA and use the SOC 3 publicly.

SOC 1 vs SOC 2: which report do customers ask for?

"SOC 2" has become the generic term for "prove your controls work". It is the phrase that circulates in procurement templates and vendor security policies, and it gets used whether or not it is the report that fits the situation. Sometimes the report that fits is a SOC 1 instead. Sometimes it is both.

They are not interchangeable. The two reports have different subject matter, different criteria and different intended readers. Sending the wrong one does not just fail to satisfy the request; it sets the clock back, because the report you actually need has to be scoped and examined from the start.

The two reports answer different questions

The AICPA describes a SOC 1 as "an examination of controls at a service organization that are likely to be relevant to user entities' internal control over financial reporting." The question it answers is narrow: does what you do for this customer affect the numbers in their financial statements, and are the controls around that dependable enough for their auditor to rely on?

A SOC 2 reports against the trust services criteria, which the AICPA's Assurance Services Executive Committee established "for use in attestation or consulting engagements to evaluate and report on controls over the security, availability, processing integrity, confidentiality, or privacy of information and systems used to provide products or services." Five categories, none of them about financial statements.

So the dividing line is not company size, industry, or how security-minded the buyer is. It is whose problem the report is meant to solve: their auditor's, or their security team's.

Who a SOC 1 is really written for

This is the part most founders get wrong. A SOC 1 is not primarily written for your customer.

The AICPA states that "SOC 1 reports are specifically intended to meet the needs of entities that use service organizations (user entities) and the CPAs that audit the user entities' financial statements (user auditors)." The second audience is somebody else's external auditor, and they read differently from a procurement reviewer. They are not assessing whether you are a safe vendor. They are deciding what evidence your controls can contribute to an opinion they have to sign.

The test for whether you are in that position is more specific than "we serve finance teams". PCAOB AS 2201 says at paragraph .B17 that AS 2601, Consideration of an Entity's Use of a Service Organization, "applies to the audit of financial statements of a company that obtains services from another organization that are part of the company's information system."

Part of the information system. Payroll processing, payment processing, claims administration, loan servicing, a billing platform whose output drives revenue recognition — those sit inside a customer's financial reporting machinery. A design tool, a support desk or a CRM used for notes generally does not, however much data it holds.

The stakes for the auditor are set by what internal control over financial reporting means. AS 2201 defines it at paragraph .A5 as "a process designed by, or under the supervision of, the company's principal executive and principal financial officers ... to provide reasonable assurance regarding the reliability of financial reporting and the preparation of financial statements for external purposes in accordance with GAAP." If part of that process runs on your servers, your controls are inside their assessment whether or not anyone has said so.

The design-versus-operation split in a SOC 1

A SOC 1 comes in two forms: one addressing how controls were designed as of a single date, one addressing how they operated across a period. AS 2601 describes both, and the consequence of supplying the wrong one is unusually concrete. Report types on the SOC 2 side are the subject of SOC 2 Type 1 vs Type 2.

AS 2601 describes the design-only report as addressing "whether such controls were suitably designed to achieve specified control objectives, and on whether they had been placed in operation as of a specific date." It then says at paragraph .12 that such a report "is not intended to provide any evidence of the operating effectiveness of the relevant controls that would allow the user auditor to reduce the assessed level of control risk below the maximum."

The period report is the one that carries weight. AS 2601 describes it at paragraph .24 as addressing "whether the controls that were tested were operating with sufficient effectiveness to provide reasonable, but not absolute, assurance that the related control objectives were achieved during the period specified." The standard then closes the loop at paragraph .52: evidence that lets the user auditor reduce the assessed level of control risk "may be obtained from the results of specific tests of operating effectiveness." Only the period report contains those test results. That is the whole difference, and it is why the two forms are not interchangeable in a financial statement audit.

Two practical consequences follow. First, where a financial statement auditor is the intended reader, a point-in-time report generally does not give them what they came for. Second, a SOC 1 does not close their file. AS 2601 says at paragraph .21 that the user auditor "should not make reference to the report of the service auditor as a basis, in part, for his or her own opinion on the user organization's financial statements." Your report feeds their work; it does not replace it. Expect follow-up questions rather than silence.

A precision worth having. The AICPA's SOC 1 guide is written to help service auditors perform a SOC 1 examination under AT-C section 320. On the SOC 2 side, AT-C section 205, Assertion-Based Examinations, is what requires the service auditor to request written representations from the responsible party in a SOC 2 engagement, and the AICPA's current SOC 2 guide reflects the requirements of SSAE No. 20 and SSAE No. 21. Ask your auditor which sections your engagement letter actually cites, rather than assuming the two reports are assembled the same way.

Not sure which one you need?Ten questions. The scorecard tells you Type 1 or Type 2 and how far out you are.

Get your score

Who a SOC 2 is really written for

A SOC 2 is read by a third-party risk function, and it is the artefact that answers a security questionnaire rather than an audit request. The subject matter is your system and the controls over it, measured against the trust services criteria — a criteria set established by the AICPA's Assurance Services Executive Committee, not written by the service organisation being examined. A SOC 1 is built the other way round, around control objectives written for the particular service — and AS 2601 notes at paragraph .35 that those objectives "may be designated by the service organization or by outside parties such as regulatory authorities, a user group, or others." So do not assume the objectives are yours to write; a regulator or a user group may have set them already.

Which categories apply is a scoping decision. Security is addressed in most engagements; availability, processing integrity, confidentiality and privacy each add criteria and effort. A buyer with a mature programme will tell you which ones they expect. A buyer without one will say "SOC 2" and mean security. What a reviewer should actually do with the report once it arrives is covered in what a vendor risk assessment should actually ask.

If the goal is something you can publish rather than something you send under NDA, the AICPA's SOC 3 is the general use version — the same control areas, without the same level of detail, and freely distributable.

A short decision path

Ask who inside the customer wants it, by name and function. Security team means SOC 2. Controller, finance or their audit firm means SOC 1, and the timing usually gives it away — those requests cluster near their fiscal year-end.
Ask whether your service is part of their information system for financial reporting. If your output becomes a journal entry, a balance or a disclosure at their end, you are in SOC 1 territory regardless of what the email said.
If they cannot answer, ask which criteria or control objectives they expect to see. A SOC 2 request comes with trust services categories. A SOC 1 request comes with financial process names.
Ask whether a period report is required, and for which period. For a SOC 1 this is usually driven by their year-end, not yours, and that date is not negotiable on their side.

In our view, step one resolves most of these in a single email, and it is worth sending before anyone scopes anything.

When the answer is both

Payroll, payments, billing and claims platforms frequently need both, because the same service is simultaneously a security exposure and a financial dependency. That is two examinations and two reports — but much of the underlying evidence is shared, particularly IT general controls over access and change management. If both are plausible for you, scope them together rather than discovering the second one a year later.

Where to start

Settle the question before you buy anything, get the answer in writing, and work backwards from their date, not yours.

If the ask is a SOC 2 and a customer's deadline is looming, the SOC 2 timeline calculator maps the ranges against it. If you are not sure which gaps would surface first, the readiness scorecard gives you an ordered list.

This is general information, not audit or legal advice. Confirm what applies to you with your auditor or counsel.

Common questions

How do you tell whether a customer needs a SOC 1 or a SOC 2?: Ask who inside their organisation wants it. A request from a security or third-party risk team is almost always a SOC 2. A request that came through their controller, their finance team or their external audit firm, often near their year-end, is usually a SOC 1, because the real audience is the auditor of their financial statements.
Does a SOC 2 cover the same ground as a SOC 1?: No. They use different subject matter and different criteria. A SOC 1 addresses controls likely to be relevant to a customer's internal control over financial reporting; a SOC 2 reports against the trust services criteria for security, availability, processing integrity, confidentiality and privacy. Neither is a substitute for the other, however thorough it is.
Who actually reads a SOC 1 report?: The AICPA says SOC 1 reports are intended to meet the needs of the entities that use service organizations and the CPAs who audit those entities' financial statements. In practice, that second group does the close reading — your customer's external auditor, deciding what evidence your controls can contribute to their audit.
Do some companies need both reports?: Yes, and it is common for payroll, payments, billing and claims platforms. The two examinations have different criteria and produce separate reports, but much of the underlying evidence overlaps, particularly IT general controls such as access management and change management. Scope them together rather than sequentially if both are likely.
Can we publish our SOC 2 report on our website?: That is what a SOC 3 is for. The AICPA describes SOC 3 reports as addressing the same control areas as a SOC 2 without the same level of detail, which is why they are general use reports that can be freely distributed. Most companies keep the SOC 2 under NDA and use the SOC 3 publicly.

Sources

SOC 1 — SOC for Service Organizations: ICFR · AICPA & CIMA
Reporting on an Examination of Controls at a Service Organization Relevant to User Entities' Internal Control Over Financial Reporting (SOC 1) Guide (2025) · AICPA & CIMA
2017 Trust Services Criteria (With Revised Points of Focus — 2022) · AICPA & CIMA
Illustrative Management Representation Letter: SOC 2 Type 2 · AICPA & CIMA
SOC 2 Reporting on an Examination of Controls at a Service Organization Relevant to Security, Availability, Processing Integrity, Confidentiality, or Privacy · AICPA & CIMA
SOC 3 — SOC for Service Organizations: Trust Services Criteria for General Use Report · AICPA & CIMA
AS 2601: Consideration of an Entity's Use of a Service Organization · Public Company Accounting Oversight Board
AS 2201: An Audit of Internal Control Over Financial Reporting That Is Integrated with An Audit of Financial Statements · Public Company Accounting Oversight Board