SOC 1 vs SOC 2 vs SOC 3: Which Report You Actually Need

Asking a supplier for "your SOC report" without saying which one is how procurement teams end up holding a SOC 3 summary for a payroll provider whose real risk sits in financial reporting, or a SOC 1 for a SaaS platform whose real risk is data security. The three System and Organization Controls (SOC) reports from the AICPA share vocabulary but answer different questions for different readers. This guide is a decision tool for both sides: which report a customer should request for each type of supplier, which report a service provider should commission first, and what to check once the report arrives, including Type 1 against Type 2, carve-outs, complementary user entity controls (CUECs), bridge letters and SOC for Supply Chain. It also sets out what to look for on identity and non-human identity (NHI) controls in each report. It is written for third-party risk, procurement, audit and compliance teams and for service providers planning attestations. For the full anatomy of each report, see the SOC 1 Guide and the SOC 2 Guide; this page focuses on choosing between them.

Key takeaways

• The question decides the report. SOC 1 answers "can my financial statement auditor rely on this supplier's controls?"; SOC 2 answers "does this supplier protect the system I depend on?"; SOC 3 answers the SOC 2 question in a summary anyone may read.
• Distribution follows depth. SOC 1 and SOC 2 reports are restricted to specified parties and contain controls, tests and exceptions. The AICPA describes SOC 3 reports as general use reports that can be freely distributed, with less detail.
• A SOC 3 is not due diligence evidence. It omits the tests and exceptions a risk assessment needs. Accept it for a first screen or low-risk suppliers only.
• Type 2 over a period is the norm for reliance. Under PCAOB AS 2601, a Type 1 report is not intended to give a user auditor a basis for reducing control risk; a Type 2 may.
• What is excluded matters as much as what is tested. Carved-out subservice organisations, CUECs you never implemented and gaps covered only by a management bridge letter are where reliance quietly fails.

The short answer

Request a SOC 1 Type 2 when the supplier processes transactions or data that flow into your financial statements: payroll, billing, claims, fund administration, revenue platforms. Request a SOC 2 Type 2 when the risk is the security, availability, confidentiality, processing integrity or privacy of a system you depend on: SaaS, cloud hosting, managed security, data processors. Some suppliers need both, for example a payroll SaaS that holds personal data. Accept a SOC 3 as a public signal or for low-tier suppliers, never as the evidence for a high-risk supplier. For suppliers that make or distribute goods, consider SOC for Supply Chain, covered in the SOC for Supply Chain guide.

Side-by-side comparison

Sources: AICPA descriptions of SOC 1 and SOC 3, and the ERISA Advisory Council comparison of SOC examinations submitted to the US Department of Labor, which describes SOC 1 distribution as restricted to the use of specified parties and SOC 2 as restricted to the service organisation and other parties who have knowledge of the system.

Each report in depth

SOC 1: reliance for financial reporting

• Threat model: errors or fraud in outsourced processing that misstate the customer's financial statements, for example unauthorised changes to a payroll calculation or a billing engine.
• Architecture in words: the service organisation writes its own control objectives (such as "logical access to the payroll application is restricted to authorised personnel") and the service auditor tests controls against them. Objectives are chosen by management, so two SOC 1 reports from different suppliers are not directly comparable.
• Failure modes: objectives that skip IT general controls; scope that misses the specific application you use; a period that ends long before your fiscal year end.
• Decision criteria: your external auditor names the supplier as relevant to ICFR, or the SOX ITGC programme depends on it. See SOX ITGCs vs SOC 1 for how user entities use it in their own testing.
• Worked scenario: a listed retailer outsources payroll. Its auditor needs a SOC 1 Type 2 covering at least most of the fiscal year, maps the CUECs (such as reviewing payroll change reports) to the retailer's own controls, and asks for a bridge letter covering the last three months of the year.

SOC 2: assurance over a system

• Threat model: breach, outage, data corruption or misuse of personal data in a system the customer depends on.
• Architecture in words: management describes the system (infrastructure, software, people, procedures, data) and selects the Trust Services Criteria categories in scope. Security (the common criteria) is always included; availability, processing integrity, confidentiality and privacy are optional. The auditor tests controls mapped to the criteria.
• Failure modes: a system boundary that leaves out the product or region you use; only security in scope when availability is your real dependency; qualified opinions or exceptions nobody reads. See How to Read a SOC 2 Report.
• Decision criteria: the supplier stores, processes or can reach your data, or an outage stops your service.
• Worked scenario: a bank onboarding a customer communications SaaS requests a SOC 2 Type 2 with security, availability and confidentiality, checks the boundary includes the EU hosting region it will use, and reviews CC6 logical access exceptions.

SOC 3: the public summary

• Threat model: none beyond SOC 2; it is a distribution format.
• Architecture in words: the auditor's opinion and management's assertion over the SOC 2 scope, with a high-level system description and no list of controls, tests or results.
• Failure modes: procurement files the SOC 3 as evidence and never sees an exception; the SOC 3 scope differs from the service bought.
• Decision criteria: early screening, low-risk suppliers, or public assurance for a provider with many small customers.
• Worked scenario: a software company publishes a SOC 3 on its trust page so small customers can self-serve, and releases the SOC 2 under NDA to enterprise customers.

Buyer decision table: which report to request

For the top tier, decide whether to rely on reports or exercise audit rights; see Right to Audit vs Assurance Reports.

Provider decision table: which report to commission

Choosing the auditor matters as much as choosing the report; see SOC 2 Auditor Selection.

Type 1 vs Type 2 in the decision

PCAOB AS 2601, which sets the user auditor's side for issuer audits, states that a Type 1 report (controls placed in operation at a date) is not intended to provide evidence of operating effectiveness, while a Type 2 report (tests over a period) may provide a basis for reducing the assessment of control risk. It also notes the report should ordinarily cover a minimum period of six months, and that tests covering a short period performed long before the audit date give less support. In practice:

• Accept a Type 1 only as an interim for a new supplier, with a dated commitment to a Type 2.
• Prefer a Type 2 period that overlaps your own reporting period or review date as much as possible.
• Treat the user auditor or reviewer as responsible: AS 2601 is explicit that the user auditor remains responsible for evaluating the evidence presented by the service auditor. The same discipline applies to any SOC 2 reviewer.

The SOC 2 Type 1 vs Type 2 guide covers the provider transition in depth.

Carve-outs, CUECs and bridge letters

Subservice organisations

Most SaaS providers run on a cloud provider. Under the carve-out method, the subservice organisation's controls are excluded and untested, and the service organisation discloses complementary subservice organisation controls (CSOCs) it expects the subservice provider to operate. Under the inclusive method, the auditor tests both, which needs the subservice provider's participation and is rarely the default. CSOCs are a disclosure, not a tested assertion, so under carve-out the user entity should obtain the subservice provider's own report, check it covers the period and scope, map the CSOCs to it, and test directly if no report exists.

Complementary user entity controls

AS 2601 describes systems designed with the assumption that certain controls would be implemented by the user organisation. Typical CUECs include provisioning and removing your own users, enforcing multi-factor authentication (MFA) on your tenant, reviewing reports and protecting API keys issued to you. The report's opinion assumes you operate them. The 2024 Snowflake breach shows the stakes: attackers used infostealer credentials against customer accounts that relied on passwords alone, and no compromise of the platform itself was found. The customer-side controls were the gap.

Bridge letters

A bridge or gap letter is a short statement issued by the service organisation's management, not the auditor, saying controls have continued to operate since the report period ended and disclosing material changes or incidents. It carries no independent assurance. Practitioner guidance describes it as typically covering up to three months, occasionally six; beyond that, ask for the next report date and interim evidence.

What to check for identity and NHI controls

Ask the provider directly how machine identities are inventoried and owned, because many reports still test human access only. The SOC 2 CC6 Logical Access Guide and Audit Readiness for AI Agents and NHIs cover the evidence side.

Implementation: a review process for customers

1. Tier suppliers by data access, financial relevance and operational dependency.
2. Map tier to report using the buyer decision table, and write it into the supplier security standard and contract templates.
3. Request and log the report type, Type 1 or 2, period, opinion, auditor, scope and subservice method.
4. Review exceptions and qualifications first, then boundary, then CUECs and CSOCs.
5. Implement CUECs and record who owns each one inside your organisation.
6. Collect subservice reports for carved-out providers that matter.
7. Manage gaps with bridge letters up to three months, then interim evidence or escalation.
8. Re-review annually and on significant change or incident.

Detection and measurement

• Report coverage: percentage of tier 1 suppliers with a current Type 2 of the right report type.
• SOC 3 reliance: number of tier 1 or tier 2 suppliers where the only evidence is a SOC 3; target zero.
• CUEC ownership: percentage of applicable CUECs with a named internal owner and evidence.
• Gap age: number of suppliers whose report period ended more than six months ago without a new report.
• Exception follow-up: percentage of reported exceptions with a documented response or compensating control.

Common failure patterns

• Accepting a SOC 3 for due diligence: no tests, no exceptions, no CUECs, so nothing to assess.
• Wrong report for the risk: a SOC 1 accepted from a SaaS provider whose risk is data security, or a SOC 2 given to an auditor who needs ICFR assurance.
• Ignoring bridge letters and gaps: relying on a report whose period ended a year ago, or treating a management letter as audited.
• Ignoring the carve-out: assuming the cloud provider is covered when its controls were excluded.
• Unimplemented CUECs: the opinion depended on controls nobody on the customer side operates, such as MFA on the tenant.
• Boundary mismatch: the report covers a different product, region or platform version from the one in use.

Framework mapping

Practitioner checklist

• Say which report and type you need in every request, not "your SOC report".
• Require SOC 1 Type 2 for suppliers relevant to financial reporting and SOC 2 Type 2 for suppliers holding data or running critical services.
• Never accept a SOC 3 alone for tier 1 or tier 2 suppliers.
• Check the system boundary matches the product and region you use.
• Read exceptions and the opinion before the control list.
• Collect subservice reports for carved-out providers and map the CSOCs.
• Assign an owner to every applicable CUEC, especially MFA, SSO and API key protection.
• Accept bridge letters for up to three months, then require interim evidence.
• Confirm the report tests service accounts and API credentials, not only human access.

Standards and references

• AICPA and CIMA: System and Organization Controls (SOC) suite of services
• AICPA and CIMA: SOC 1, SOC for Service Organizations: ICFR
• AICPA and CIMA: SOC 3, SOC for Service Organizations: Trust Services Criteria for General Use Report
• AICPA and CIMA: 2017 Trust Services Criteria (With Revised Points of Focus, 2022)
• AICPA and CIMA: Description criteria for SOC for Supply Chain
• PCAOB: AS 2601 Consideration of an Entity's Use of a Service Organization
• US Department of Labor, ERISA Advisory Council: Appendix A, comparison of SOC examinations
• Compass IT Compliance: Carve-out vs inclusive method for subservice organisations

Related NHI Mgmt Group resources: SOC 2 Guide · SOC 1 Guide · How to Read a SOC 2 Report Guide · Third-Party Attestation Comparison Map · Third-Party Risk Management Guide