SOC 1, SOC 2, or SOC 3: Which Report Is Your Customer Asking For?

Look at who inside the customer is asking, because that identifies the report faster than any comparison table. If the request comes from finance, the controller, or their external financial statement auditor, they want a SOC 1: an examination of the controls at your organisation that are relevant to their internal control over financial reporting. If it comes from the security team, procurement, or a vendor risk questionnaire, they want a SOC 2: an examination against the AICPA Trust Services Criteria. If somebody wants something they can post on a website or hand out without an NDA, that is SOC 3, which is not a third audit at all but a short general-use version of a SOC 2 you already have.

The three sit inside the AICPA's SOC suite of services for service organisations. What follows is what each one actually examines, why two of them are restricted-use documents, and the cases where you genuinely need more than one.

Key takeaways

• Look at who inside the customer is asking. Finance, the controller or their financial statement auditor means SOC 1. The security team, procurement or a vendor risk questionnaire means SOC 2.
• SOC 1 has no fixed criteria set. You define control objectives relevant to your customers' financial reporting, which is why two SOC 1 reports can look nothing alike.
• SOC 3 is not a third audit. It is a general-use summary derived from a SOC 2, and it omits exactly the sections a security reviewer wants to read.
• Type I and Type II are a separate axis from the report number, so "SOC 1 Type II" is a real and common document.
• SOC 1 and SOC 2 are restricted-use documents. Distribute them under NDA through a defined process, and give a SOC 3 or a scope-and-opinion summary to anyone who has not signed anything.

SOC 1: controls that land in someone else's financial statements

A SOC 1 exists because of a specific problem in financial auditing. When a company outsources a process that feeds its books, its own auditor cannot see the controls over that process, because the controls sit inside your systems. Rather than send every customer's auditor to inspect you individually, you commission one examination of those controls and give the report to all of them.

That defines who needs one. Payroll processors. Payment processors and billing platforms whose output becomes revenue in the customer's ledger. Claims administrators. Fund administrators and transfer agents. Loan servicers. Anything that calculates, records or moves numbers that end up in a customer's financial statements.

It also defines the criteria, which is where SOC 1 differs most sharply from SOC 2. There is no fixed criteria set. You define control objectives relevant to your customers' financial reporting (completeness of transactions processed, accuracy of calculations, authorisation, restricted access to the processing environment) and the auditor tests the controls you designed to meet them. Two SOC 1 reports from different companies can look nothing alike, and that is correct.

If your customers are public companies, expect their auditors to lean on your SOC 1 as part of their own internal control work, which raises the bar on your IT general controls specifically. What those look like is the subject of our SOX ITGC guide.

SOC 2: controls against a published criteria set

A SOC 2 examines your controls against the AICPA's Trust Services Criteria, the 2017 criteria with revised points of focus issued in 2022, covering Security, Availability, Processing Integrity, Confidentiality and Privacy. Security is mandatory; the other four are included only if you choose them, and the right time to choose one is when a customer contract names it.

The audience is a security reviewer rather than an accountant. The question is not whether your processing is accurate for financial purposes; it is whether you protect the system and the data in it. This is the report the overwhelming majority of software companies are being asked for when a deal stalls on "we need your SOC 2".

One point that trips people up: Type I and Type II are not a SOC 2 thing. They describe whether an examination covers design at a point in time or design and operating effectiveness over a period, and they apply to SOC 1 and SOC 2 alike. So "SOC 1 Type II" is a real and common document. Which type you need, and the sequencing that stops a Type I from being wasted spend, is covered in our Type I versus Type II piece.

SOC 3: the version you are allowed to publish

A SOC 3 is a short report you are allowed to publish. The AICPA describes SOC 3 as addressing the same trust services categories as SOC 2 but without the same level of detail, which is why SOC 3 reports "are considered general use reports and can be freely distributed" (AICPA). It carries the auditor's opinion and a brief system description. What it leaves out is Section 3's detailed system description and Section 4's description of tests performed and their results, which is exactly the material a security reviewer wants.

Two consequences. First, it is a summary rather than a cheaper alternative: it omits the sections a reviewer reads, so publishing one does not remove the request for the full report. Second, it is a marketing artifact, not a diligence artifact. It is genuinely useful on a trust page or in a sales deck, and it will not satisfy a vendor risk team, who will come back and ask for the full report under NDA.

The AICPA also publishes SOC for Cybersecurity, an entity-level examination of a cybersecurity risk management programme rather than a system-level one, and SOC for Supply Chain. Both are real and both are rare in software procurement; if a customer asks for one, they will know why, and it will not be a substitute for the SOC 2 they also want.

Why your report arrives under NDA

SOC 1 and SOC 2 reports are restricted-use documents. They are intended for management, existing customers, and those customers' auditors, and the report itself says so. That is not vendor paranoia; it is a property of the deliverable, because the report contains a detailed description of your control environment and every place it failed during the period, which is useful to a customer evaluating you and useful to an attacker mapping you.

SOC 3 is the general-use member of the family, which is its entire reason to exist.

Practical consequences: put a process behind report distribution rather than emailing the PDF to anyone who asks, and expect the same discipline from your own vendors. If a prospective customer who has not signed anything wants proof today, a SOC 3 or a summary of scope and opinion is the right answer, not the full report.

When you need more than one

More common than people expect, and the economics are better than they fear.

A payments platform typically needs both: SOC 1 because its output becomes revenue in customers' books, SOC 2 because its customers' security teams also review it. Same for payroll platforms, billing systems, and anything in the revenue path for a public company.

The good news is that the control environments overlap heavily even though the criteria do not. Access management, change management and IT operations underpin both examinations, so the evidence largely serves both once you tag it to both, which is the discipline described in reusing evidence across frameworks. What does not overlap is the top layer: SOC 1's control objectives are yours to define around financial reporting, and SOC 2's criteria are published and fixed.

The wrong reason to get both is symmetry. If no customer's finance function has ever asked and nothing you do touches a customer's ledger, a SOC 1 is a report nobody will read.

What none of them is

None of the three is a certification, and none has a pass mark. Each ends in an auditor's opinion plus, for a Type II, a description of tests and their results, which is where exceptions appear. A report with exceptions and an unqualified opinion is a normal, honest report. We spell out how opinions and exceptions actually work in can you fail a SOC 2 audit.

How to answer the request this week

Reply to the person who asked with two questions: which report type does your policy require, and does it need to cover a period or a single date? You will resolve the SOC 1 versus SOC 2 question immediately, because the requester either says "our auditors need it for our year end" or "our security team needs it for vendor review", and you will learn whether a Type I buys you time.

Then check the scope you actually hold against what they are buying from you, because the second most common problem in this space is a real report that covers a different product line. Reading a report for that specifically is the subject of how to read a vendor's SOC 2 report.

Where Top Floor fits

We do the readiness work for SOC 1 and SOC 2 and we issue neither, because the opinion belongs to an independent licensed CPA firm. That separation is why we can tell you that you do not need a SOC 1, which is advice a firm selling SOC 1 examinations is poorly placed to give. If you are trying to decide which examination to scope, or whether the request in front of you is real, that conversation is readiness work and it is usually short.

Frequently asked questions

What is the difference between SOC 1 and SOC 2?

SOC 1 examines controls at your organisation that are relevant to your customers' internal control over financial reporting, against control objectives you define. SOC 2 examines controls against the AICPA's published Trust Services Criteria for security, availability, processing integrity, confidentiality and privacy. The quickest test is who is asking: a customer's finance function or their financial statement auditor wants SOC 1, a security team or procurement wants SOC 2. Companies whose service feeds customer ledgers, such as payroll and payments platforms, frequently need both.

Is SOC 3 easier or cheaper than SOC 2?

Neither, because it is not an alternative. A SOC 3 is derived from a SOC 2 examination, so the examination happens either way; the SOC 3 is an extra deliverable that omits the detailed system description and the description of tests and results. It is a general-use document you can publish without an NDA, which makes it useful for a trust page or a sales deck. A vendor risk team reviewing you seriously will ask for the full SOC 2 anyway.

Can we give our SOC 2 report to anyone who asks?

No. SOC 1 and SOC 2 reports are restricted-use documents intended for management, customers, and customers' auditors, and the report says so on its face. They describe your control environment in detail, including every place it failed during the period. Distribute them under NDA through a defined process, and use a SOC 3 or a scope-and-opinion summary for anyone who has not signed anything.

Do Type I and Type II apply to SOC 1 as well?

Yes. Type I means the examination covers the design of controls at a point in time; Type II means it covers design and operating effectiveness over a period. Both apply to SOC 1 and SOC 2, so a SOC 1 Type II is a normal document. The type is a separate axis from the report number, and customers sometimes specify one without the other, which is worth clarifying before you scope anything.