Learn · SOC Reports
Types of SOC Reports:
SOC 1, SOC 2 & SOC 3
SOC — System and Organization Controls — is the AICPA's family of attestation reports on a service organization's controls. SOC 1 speaks to your customers' financial reporting, SOC 2 to the security of their data, and SOC 3 is the public summary of a SOC 2. Here is what each covers, who reads it, and where Type 1 and Type 2 fit.
The numbers are not versions. SOC 2 is not an upgraded SOC 1, and SOC 3 is not the newest release — they are different reports for different readers. The Type 1 / Type 2 distinction is a separate axis that cuts across SOC 1 and SOC 2 alike.
Plain-English explainer · AICPA SOC suite · Last reviewed July 2026
SOC (System and Organization Controls) is a family of attestation reports defined by the AICPA. SOC 1 covers controls relevant to customers’ financial reporting; SOC 2 covers security, availability, processing-integrity, confidentiality, and privacy controls; SOC 3 is the general-use public summary of a SOC 2. SOC 1 and SOC 2 each come as Type 1 (a point in time) or Type 2 (a period). The numbering reads like a sequence — it is not. SOC 2 is not an upgraded SOC 1, and SOC 3 is not the latest release: each report answers a different question for a different reader. SOC 1 exists for your customers’ finance teams and the auditors of their financial statements; SOC 2 for their security and vendor-risk teams; SOC 3 for the general public. All three are attestation examinations performed by independent licensed CPA firms under the AICPA’s attestation standards — none is a certification, and no badge or registry sits behind any of them. If a customer has just asked you for “a SOC report” and you are not sure which one they mean, the map below sorts it out — and if the data-security report is your destination, start with what SOC 2 is.
A note on the name: SOC originally abbreviated “Service Organization Control,” and the AICPA later renamed the suite “System and Organization Controls” as it grew beyond service-organization reports to include entity-level ones. The old expansion still circulates, which is harmless — but it explains why the family now contains reports, like SOC for Cybersecurity, that are not about a service organization at all.
The Family
Three Reports, Three Different Readers
The fastest way to keep the family straight is to ask who reads each report — the subject matter, criteria, and rules of distribution all follow from the audience.
SOC 1 — your customers’ financial reporting
A SOC 1 examines controls at a service organization that are relevant to its customers’ internal control over financial reporting (ICFR). The test is simple: could an error in your service put a wrong number in your customers’ financial statements? Payroll processors, loan servicers, fund administrators, and claims processors all answer yes — a mis-run payroll or a mis-stated fund valuation lands directly in someone else’s books. The readers are those customers’ finance teams and, above all, their financial-statement auditors, who rely on the report when they audit those books.
Mechanically, SOC 1 is the odd one out. It is performed under AT-C section 320 — the standard created by SSAE 18, with an SSAE lineage that now runs to SSAE 23, effective for engagements beginning on or after December 15, 2025. Its control objectives are defined by management to fit the service rather than drawn from a fixed AICPA catalog, and its description requirements live inside AT-C 320 itself (paragraphs .16–.17) — SOC 1 has no DC section 200. Like SOC 2, it is a restricted-use report, shared under NDA.
SOC 2 — your customers’ data
A SOC 2 examines controls over the systems a service organization uses to hold or process customer data — the default ask for SaaS companies, MSPs, data centers, and data processors, or any vendor whose failure would be a security incident rather than an accounting one. Its readers are your customers’ security, vendor-risk, and procurement teams, usually as part of an enterprise security review.
Controls are evaluated against the AICPA Trust Services Criteria: Security is mandatory in every SOC 2, while Availability, Processing Integrity, Confidentiality, and Privacy are optional categories added when they match what you promise customers. The system description is prepared under DC section 200 — description criteria that exist only for SOC 2 — and the examination runs under AT-C sections 105 and 205. The result is a restricted-use report shared under NDA. New to the framework? Start with what SOC 2 is; if you already have a report in hand, how to read a SOC 2 report walks through all five sections.
SOC 3 — the public summary of a SOC 2
A SOC 3 is the general-use companion to a SOC 2 Type 2: the same examination, by the same auditor, over the same period — repackaged for public distribution. What it drops is the detail reviewers rely on: there are no Section 4 controls-and-tests tables, so a reader sees the auditor’s opinion and a high-level system overview, not the individual controls, test procedures, or results.
That trade defines its use. A SOC 3 can be posted on your website, linked in proposals, and handed to anyone — genuinely useful for marketing, and genuinely useless for vendor-risk diligence, which is why security reviewers who find your SOC 3 will still ask for the full SOC 2 under NDA. And there is no standalone path: you cannot get a SOC 3 without the underlying SOC 2 examination. Our SOC 3 page covers when adding one makes sense.
Side by Side
SOC 1 vs SOC 2 vs SOC 3 at a Glance
Six dimensions separate the three reports. If you remember only one row, make it distribution — it decides what you may do with the report once you have it.
| Dimension | SOC 1 | SOC 2 | SOC 3 |
|---|---|---|---|
| Subject matter | Controls relevant to customers’ internal control over financial reporting (ICFR) | Controls over the security, availability, processing integrity, confidentiality, and privacy of customer data and systems | The same subject matter as the underlying SOC 2, summarized for a general audience |
| Primary audience | Customers’ finance teams and their financial-statement auditors | Customers’ security, vendor-risk, and procurement teams | The general public — prospects, partners, website visitors |
| Criteria | Management-defined control objectives; description requirements sit inside AT-C 320 itself — there is no DC 200 for SOC 1 | AICPA Trust Services Criteria — Security mandatory, four optional categories; description prepared under DC section 200 | Trust Services Criteria, inherited from the underlying SOC 2 examination |
| Attestation standard | AT-C section 320 (created by SSAE 18; the SSAE lineage now runs to SSAE 23) | AT-C sections 105 and 205 | The same examination as the underlying SOC 2 Type 2 — there is no standalone SOC 3 path |
| Distribution | Restricted use — shared with customers and their auditors under NDA | Restricted use — shared under NDA | General use — may be posted publicly |
| Who typically asks | Payroll, loan-servicing, fund-administration, and claims customers — prompted by their financial-statement auditors | Enterprise security reviews and vendor-risk questionnaires — the default ask of SaaS vendors, MSPs, data centers, and processors | No one demands it — service organizations volunteer it as public proof |
Two rows do most of the work in practice. Subject matter decides which report your customers will ask for; distribution decides what happens afterwards. Restricted use means the report is intended for specified parties — the service organization, its customers, and those customers’ auditors — so SOC 1 and SOC 2 reports travel under NDA, typically through a sales or trust-center process, and never onto a public webpage. General use means anyone may read it, which in this family describes SOC 3 alone. A vendor that posts a “SOC 2 report” publicly has either posted a SOC 3 under a loose label or misunderstood the restriction. For the SOC 1-vs-SOC 2 decision in depth, including how organizations run both, see SOC 1 vs SOC 2.
The Other Axis
Type 1 vs Type 2 Cuts Across the Numbers
Half the confusion in SOC conversations comes from reading “SOC 2 Type 2” as one compound version number. It is two independent choices. The numerals — SOC 1, 2, 3 — name the report family: what subject matter, for which audience. The Types name the depth of the examination: Type 1 covers the design of controls at a point in time; Type 2 covers design plus operating effectiveness over a period, typically 3–12 months. The axes combine — SOC 1 Type 1, SOC 1 Type 2, SOC 2 Type 1, SOC 2 Type 2 — and SOC 3 sits outside the pattern, since it is derived from a SOC 2 Type 2 and has no Type variants of its own. The full comparison lives in our Type 1 vs Type 2 guide.
Type 1 — a point in time
- The opinion speaks “as of” a single date: were controls suitably designed and implemented on that day.
- Exists for SOC 1 and SOC 2 alike — a SOC 1 Type 1 is design-only in exactly the same way.
- A common first milestone for a new compliance program; most buyers accept it once, then expect a Type 2.
- Says nothing about whether controls kept operating — that is precisely what it does not cover.
Type 2 — a review period
- The opinion covers a stated period — typically 3–12 months — and addresses operating effectiveness throughout it.
- The report shows the auditor’s tests of each control and the results, including any exceptions noted.
- The version enterprise buyers and user auditors usually insist on, refreshed on an annual cycle.
- The prerequisite for a SOC 3 — the public summary can only be built on a SOC 2 Type 2.
In practice the combinations arrive as shorthand in customer requests. “SOC 2 Type 2” is what enterprise security reviews mean by default — the data-security report, with operating effectiveness tested over a period. A customer’s audit firm asking about payroll controls means a SOC 1, and almost always a Type 2, because financial-statement auditors need coverage over the period they are auditing, not a single day. When a request just says “SOC report,” confirm both axes before you scope anything: which family, and which Type.
The Wider Suite
SOC for Cybersecurity & SOC for Supply Chain
The AICPA suite includes two further reports you will occasionally see referenced. Both are genuine engagements; neither comes up often.
SOC for Cybersecurity
An entity-wide report on an organization’s cybersecurity risk-management program — the whole business, not one service system. It is general use, written for broad audiences such as boards, investors, and business partners rather than for a specific customer relationship.
SOC for Supply Chain
A report on the controls of a system that produces, manufactures, or distributes products, giving business customers assurance over what arrives from the supply chain. Relevant to manufacturers and distributors rather than service providers.
Compared with SOC 1 and SOC 2, both are rarely requested — we mention them mainly so the names don’t confuse. When a customer asks for “your SOC report” without qualification, they mean one of the core three, and usually a SOC 2 Type 2.
Decision Guide
Which SOC Report Do You Need?
The question is never “which SOC report is best” — it is what your customers rely on you for.
- 1They rely on you for their financial numbers → SOC 1. If your service feeds payroll runs, loan balances, fund valuations, or claims payments into customers’ financial statements, their auditors will ask for a SOC 1 — usually Type 2. Start with our SOC 1 services overview.
- 2They rely on you to hold or process their data → SOC 2. If you are a SaaS product, MSP, data center, or data processor, security reviews and vendor questionnaires will ask for a SOC 2 — almost always Type 2, shared under NDA. See our SOC 2 services overview.
- 3You want proof you can publish → SOC 3, after the SOC 2. A SOC 3 rides on a completed SOC 2 Type 2 examination; you cannot commission one on its own. Complete the SOC 2 Type 2, and the general-use summary can be added as the public-facing companion for your website and sales collateral.
- 4They rely on you for both — money and data → SOC 1 + SOC 2 together. Payroll and HR-tech platforms are the classic case: the payroll figures make it SOC 1 territory, the employee data makes it SOC 2 territory. Running both examinations over aligned periods is common and avoids duplicated evidence work.
One structural note that applies to every branch: preparing for a SOC examination and issuing the opinion are different jobs. Tranquility Cybersecurity (TCSA) handles the first — scoping which report and which Type your customer commitments actually require, readiness assessment, gap remediation, evidence, and description drafting — and coordinates the examination through empanelled, independent licensed CPA firms, who alone issue the opinion. That separation is how the profession keeps the attestation independent, across 500+ audits we have delivered.
Types of SOC Reports — Common Questions
SOC 1 vs SOC 2 vs SOC 3, Type 1 vs Type 2, and what you may share publicly.
What are the types of SOC reports?
Three core types. SOC 1 covers controls relevant to customers’ internal control over financial reporting; SOC 2 covers controls over the security, availability, processing integrity, confidentiality, and privacy of customer data; SOC 3 is the general-use public summary of a SOC 2. SOC 1 and SOC 2 each come as Type 1 (control design at a point in time) or Type 2 (design plus operating effectiveness over a period). The AICPA suite also includes SOC for Cybersecurity and SOC for Supply Chain, which are rarely requested by comparison.
What is the difference between SOC 1 and SOC 2?
Subject matter and audience. SOC 1 examines controls relevant to customers’ financial reporting — read by their finance teams and financial-statement auditors, tested against management-defined control objectives under AT-C section 320. SOC 2 examines controls over the security of customer data — read by security and vendor-risk teams, tested against the AICPA Trust Services Criteria under AT-C sections 105 and 205. Rule of thumb: if your mistake would misstate a customer’s books, that points to SOC 1; if it would expose a customer’s data, that points to SOC 2.
What is a SOC 3 report?
A SOC 3 is the general-use summary of a SOC 2 Type 2 examination — same auditor, same examination, same period, but without the detailed controls-and-tests tables of a full report. Because it is general use, it can be posted publicly on a website, which makes it useful for marketing and insufficient for vendor-risk diligence; reviewers who see a SOC 3 typically still request the full SOC 2 under NDA. You cannot obtain a SOC 3 without the underlying SOC 2 examination.
Is SOC 2 Type 2 the same as SOC 2?
“SOC 2” names the report family; “Type 2” names the depth of the examination. A SOC 2 comes either as Type 1 — control design as of a single date — or Type 2 — design plus operating effectiveness over a review period, typically 3–12 months, with the auditor’s tests and results in the report. When a buyer says “send us your SOC 2,” they nearly always mean a SOC 2 Type 2, but it is worth confirming before you scope an examination.
Can we publish our SOC 2 report?
No. A SOC 2 (like a SOC 1) is a restricted-use report intended for the service organization, its customers, and other specified parties — it is shared under NDA, not posted publicly. The report designed for publication is SOC 3, the general-use summary of a SOC 2 Type 2. The usual pattern is to publish the SOC 3 or a short statement that a SOC 2 Type 2 report is available under NDA, and share the full report through your sales or trust process.
Do we need both SOC 1 and SOC 2?
If customers rely on you for both their financial numbers and their data, commonly yes. Payroll and HR-tech platforms are the standard example: processed payroll feeds customers’ financial statements (SOC 1 territory) while employee records are sensitive personal data (SOC 2 territory). The two remain separate reports with separate opinions, but organizations typically run them over aligned periods, reusing much of the same control evidence across both examinations.
What are SOC for Cybersecurity and SOC for Supply Chain?
Two further reports in the AICPA suite. SOC for Cybersecurity is a general-use, entity-wide report on an organization’s cybersecurity risk-management program, aimed at broad audiences such as boards and investors rather than specific customers. SOC for Supply Chain reports on the controls of a system that produces, manufactures, or distributes products. Both are rarely requested compared with SOC 1 and SOC 2 — an unqualified request for “a SOC report” almost always means one of the core three.
Related reading: the Learn hub, what SOC 2 is, how to read a SOC 2 report, SOC 1 vs SOC 2 in depth, Type 1 vs Type 2, and our SOC 1, SOC 2, and SOC 3 services. More terms in the compliance glossary.
Written By Expert Auditors
Get in touch
Book a free consultation or send us your requirements. We respond within 24 hours.
Quick Call
Pick a time slot
Send Requirements
Get a custom quote in 24 hours