What Is SOC 3, and Why Do Vendors Publish It Instead of SOC 2?

Type "what is soc 3" into a search bar and most results explain the acronym and stop there. The more useful question for a buyer is why a vendor would publish a SOC 3 at all when SOC 2 is the report everyone actually asks for in a questionnaire. The two documents come from the same audit engagement, tested against the same Trust Services Criteria, by the same audit firm, over the same period. SOC 3 is the version a vendor can hand to anyone without a non-disclosure agreement. SOC 2 is the version with the control descriptions, the test results and any exceptions, and it almost always requires one. When we pulled vendor pairings across the CertReports index on 2026-10-10, a large share of SOC 3 listings had no SOC 2 report captured anywhere in the same evidence set, which tells a buyer something specific about what they are, and are not, being shown.

What a SOC 3 report actually is

SOC 3 sits inside the AICPA's System and Organization Controls suite, alongside SOC 1 and SOC 2. All three are produced under the same auditing standard, and SOC 2 and SOC 3 are both assessed against the Trust Services Criteria, with security as the mandatory category and availability, confidentiality, processing integrity and privacy added at the vendor's choice. SOC 3 is described by the AICPA as a general use report, meaning it is written for an audience that needs assurance about controls but does not need, or is not entitled to see, the detail behind that assurance.

• A management assertion, a short statement from the vendor describing the system and its control objectives
• The independent auditor's opinion, a brief paragraph saying whether controls were suitably designed and operating effectively
• A condensed system description, usually a page or two rather than the dozens found in a SOC 2
• No list of individual controls tested, no sample sizes, and no description of any exceptions the auditor noted

That last point is the one most buyers miss. A SOC 2 report lists every control the auditor examined and states plainly where a control did not operate as designed during the period. A SOC 3 strips all of that out. It tells you the auditor reached a clean opinion overall, but not what they looked at to get there.

SOC 2 and SOC 3 come from one engagement, not two audits

A vendor does not run a separate audit to get a SOC 3. The auditor performs one engagement against one set of criteria over one period, usually twelve months for a report covering a span of time rather than a single date. Our explainer on SOC 2 Type I vs Type II covers that point-in-time versus period-of-time distinction in more depth, and it carries over to SOC 3: in practice almost all SOC 3 reports are drawn from a Type II style examination, because a point-in-time opinion gives a general audience little to act on. The vendor then asks the audit firm to issue two outputs from the same work: the restricted-use SOC 2 for buyers who sign an NDA, and the general-use SOC 3 for anyone else, including the marketing team.

Why vendors publish SOC 3 instead of releasing SOC 2

There is nothing improper about publishing a SOC 3 on its own. It is designed for exactly that purpose. A vendor can put the SOC 3 seal on a website footer, attach the PDF to a sales deck, or drop it into a trust centre without worrying about who downloads it, because it contains nothing a competitor or the general public should not see. SOC 2 is different. It typically includes system architecture detail, named subservice organisations, and specific control exceptions, so vendors gate it behind an NDA or a request form and distribute it only to prospective and existing customers.

The friction that creates is where the pattern in the index becomes relevant. Requesting a SOC 2 takes an extra step: filling in a form, naming a point of contact, sometimes waiting days for legal to countersign an NDA. A SOC 3 badge requires none of that. For a vendor optimising a public trust centre for conversion, publishing the SOC 3 alone and leaving the SOC 2 as available on request only is a reasonable trade-off. For a buyer trying to clear a vendor security review in one sitting, it means the document that answers most of the questions on a questionnaire is one step further away than the badge suggests.

What the pairing looks like across the index

Because SOC 3 and SOC 2 come from the same work, a vendor that has a real, current SOC 2 behind its SOC 3 can usually produce it within a short request cycle. The useful signal for a buyer is not whether a SOC 3 exists, it is whether a SOC 2 exists anywhere alongside it, even gated. The SOC 3 framework page and the SOC 2 framework page list vendors separately for this reason, and cross-referencing the two is the fastest way to see which vendors publish both and which publish the public summary on its own with no paired SOC 2 captured in the same evidence set.

~1 in 3

SOC 3 listings with no paired SOC 2 evidence

in the CertReports index on 2026-10-10

Type II

most common report type behind a public SOC 3

in the CertReports index on 2026-10-10

Security

the only Trust Services Criterion present in every SOC 3 sampled

in the CertReports index on 2026-10-10

Paylocity's trust centre entry is a useful case for seeing this distinction in practice, because it states SOC 1 Type II and SOC 2 Type II with the report type included rather than leaving the framework as a bare name. Look at whether a SOC 3 is listed alongside those two, and whether the SOC 2 itself is offered as a downloadable artefact or only reachable through a request form.

Paylocity · Trust report

Finance and accounting · Public evidence as of 26 Oct 2026

Visit trust centreFull evidence

Framework overview

CertReports state for each framework with public evidence: 1 verified, 3 vendor-stated.

• SOC 2Vendor-statedType II report
• DPFVerifiedValid to 2 Feb 2027
• ISO 27001Vendor-statedTrust centre · 30 Sep 2026
• SOC 1Vendor-statedType II report

3Documents and agreements

Legal and review documents Paylocity publishes or offers, as of 30 Sep 2026.

• Business associate agreement · Public
• Subprocessor list · On request
• Privacy policy · Public

1Security practices

Public statements from Paylocity, shown as statements, not attestations, as of 30 Sep 2026.

• Penetration testing · report available

SOC 3 reports are designed to meet the needs of users who need assurance about the controls at a service organization relevant to security, availability, processing integrity, confidentiality or privacy, but do not have the need for, or the knowledge necessary to make effective use of, a SOC 2 Report.

What a SOC 3 does not tell you, and why that matters

A clean SOC 3 opinion can sit over a SOC 2 that still contains a noted exception, because the auditor's overall conclusion can remain unqualified even when one control did not operate perfectly for part of the period. The SOC 3 will not say that. It also will not name the subservice organisations the vendor relies on, will not describe which complementary user entity controls the vendor expects a customer to run, and will not give the system boundary description a reviewer needs to judge scope. Our guide on how to read a SOC 2 report walks through exactly where that detail sits inside the full report, which is also the clearest way to see what the SOC 3 version has left out.

There is a separate, related gap worth flagging: a SOC 2 report covers a fixed period that ends on a specific date, and vendors sometimes bridge the gap to the next report with a short letter rather than a new audit. If a vendor's trust centre shows only a SOC 3 with no date visible, you also cannot tell whether the underlying SOC 2 period has lapsed. Our explainer on what a bridge letter is covers how much weight that document can reasonably carry.

1. 1

   Check the framework pages first

   Look up the vendor's SOC 3 and SOC 2 listings separately to see whether both are captured for the same engagement.

2. 2

   Ask specifically for the SOC 2

   Request the SOC 2 by name in your vendor security questionnaire, not just "SOC report", since a vendor may otherwise default to sending the SOC 3.

3. 3

   Confirm the report type and period

   Once you have the SOC 2, check it is Type II, not Type I, and check the period end date against today.

4. 4

   Read the exceptions section

   Go straight to the section listing test results and exceptions rather than the opinion letter, since that is where the SOC 3 has nothing equivalent.

5. 5

   Check for a bridge letter if the period has ended

   If the SOC 2 period ended more than a few months ago, ask whether a bridge letter covers the gap to the next report.

Does a SOC 3 cover the same ground as SOC 2

Not in the sense a buyer usually means by cover. A SOC 3 is drawn from the same engagement and the same criteria, so it does not add scope the SOC 2 lacks, and it does not confirm anything the SOC 2 did not also test. What it covers is the headline conclusion only: the auditor's opinion that controls were suitably designed and, for a period-of-time report, operating effectively. It does not cover the control list, the testing approach, the sample sizes, or any exceptions, all of which live exclusively in the SOC 2. If a procurement process requires evidence of specific controls, a SOC 3 on its own will not satisfy it, and asking for the SOC 2 directly is the only way to close that gap. For a side-by-side look at when a buyer should ask for SOC 2 versus a certification like ISO 27001 instead, see SOC 2 vs ISO 27001: what to ask vendors for.