SOC 1 vs SOC 2: Which Report You Actually Need and How to Read the One You Get

SOC 1 and SOC 2 are often mentioned together, but they serve very different purposes.

The confusion usually starts when a customer or auditor asks for “a SOC report,” without specifying which one. 

Teams assume they are interchangeable or that one could be a substitute for the other. But choosing the wrong report can create a mismatch between what you prove and what the buyer is trying to validate.

At a high level, the distinction is simple. A SOC 1 report focuses on controls relevant to financial reporting. However, a SOC 2 report focuses on how you protect customer data and operate securely. 

The complexity comes from how that distinction plays out in real business scenarios, where the right choice depends on your role in the customer’s workflow, the type of data you handle, and the risks your service introduces.

This is why SOC 1 is typically used by service organizations that impact financial statements, such as payroll processors or payment platforms. SOC 2, on the other hand, is expected of SaaS providers, infrastructure platforms, and any company that handles customer data.

This guide breaks down SOC 1 vs. SOC 2 and covers everything from:

• Which report to request from which vendor
• Why the wrong report type creates a measurable compliance gap
• How to read a SOC 2 report once you receive it
• What CUECs and bridge letters are and why they matter
• Why SOC 2 certification does not guarantee what procurement teams assume it does.

What SOC 1 and SOC 2 Measures

SOC 1 reports assess a service organization’s internal controls over financial reporting (ICFR) under the SSAE 18 standard. 

SOC 2 reports assess controls mapped to the AICPA’s Trust Services Criteria — Security, Availability, Processing Integrity, Confidentiality, and Privacy.

SOC 1 exists because financial auditors need assurance

When a service provider processes transactions that touch your financial statements, your financial auditor needs to know that their systems don’t introduce errors. 

SOC 1 covers transaction processing accuracy, data integrity in financial workflows, and reconciliation controls. It is governed by SSAE 18 (Statement on Standards for Attestation Engagements No. 18).

SOC 2 exists because security teams need assurance

When a service provider handles your data or delivers IT services, your security team needs to know that access is controlled, incidents are handled, and availability commitments are honored. SOC 2 is governed by the AICPA Trust Services Criteria.

The naming convention is sequential by number but not by scope or difficulty. SOC 2 is NOT a harder version of SOC 1. SOC 3 is NOT an upgrade from SOC 2. They measure fundamentally different things.

A few other operational facts worth knowing about SOC 1 and SOC 2:

• Both require an independent CPA firm to perform the examination, and neither is a self-assessment or vendor self-certification.
• If you still hear “SAS 70” in your organization, that is the predecessor standard retired in 2011. SSAE 16 replaced it, then SSAE 18 replaced SSAE 16 in 2017.
• Platforms like AWS, Azure, and Google Cloud maintain separate SOC 1 and SOC 2 reports, each covering different assurance objectives. Access to these reports typically requires an NDA, because they serve different audit and risk functions.

Key differences between SOC 1 and SOC 2

SOC 1 vs SOC 2 vs SOC 3: The Full Framework Map

SOC 3 is a summarized version of a SOC 2 report that can be publicly shared. It contains the auditor’s opinion but also omits the detailed system description, control test procedures, and test results. 

SOC 3 is useful as marketing collateral, but does not satisfy vendor risk due diligence requirements in enterprise procurement.

SOC 3 uses the same Trust Services Criteria as SOC 2. What it removes is everything that makes SOC 2 operationally useful:

• The management description of the system (which tells you what’s actually in scope)
• The test matrices (which tell you what the auditor tested)
• Exceptions and deviations (which tell you where controls failed)

Cloud providers like Google publish downloadable SOC 3 reports publicly, but to get access to their SOC 1 and SOC 2 documentation requires an NDA.

Comparison between SOC 1, SOC 2, and SOC 3 reports

SOC 2 Type Reports: Why Experienced Practitioners Treat SOC 2 Type I as a Placeholder

A Type I report assesses whether controls were designed correctly at a single point in time. A Type II report tests whether those controls operated effectively over a defined period, usually 6 to 12 months. 

Experienced practitioners treat Type I as a placeholder because design without operating evidence proves nothing.

What auditors do differently when approaching Type I and Type II

• Type I: The auditor inspects control documentation, interviews management, and confirms that the control descriptions match the environment on one specific day. 
• Type II: The auditor tests a sample of transactions and events across the full audit window, such as:
  • Access control (CC6): Checking whether access reviews happened quarterly and not whether the policy says they should. 
  • Change management (CC8): Confirming that every deployment went through the approval workflow.

Must ask for your vendors: “When does your current Type II audit window end, and when is the next report expected?” If they can not answer, the engagement may have lapsed.

When SOC 2 Type I is acceptable vs. when SOC 2 Type II is required

Breakdown on when SOC 1 is acceptable and when SOC 2 is needed

Trust Services Criteria — What SOC 2 Actually Measures (and What’s Optional)

SOC 2 reports are built on five Trust Services Criteria:

• Security (mandatory)
• Availability
• Processing Integrity
• Confidentiality
• Privacy

Only Security is required. The others are optional and selected based on the vendor’s commitments and the nature of the data being processed.

Security (CC1–CC9) 

Covers logical and physical access management controls, system operations and monitoring, change management, and risk mitigation. 

This maps to NIST SP 800-53 control families, including access control, configuration management, incident response and audit logging.

What the auditor tests for SOC 2 security:

• Access approvals and provisioning workflows
• Deprovisioning timelines for terminated users
• Enforcement of MFA for privileged accounts
• Frequency and completion of access reviews

Availability (A1)

Covers system uptime commitments, disaster recovery, and capacity monitoring. Required if the vendor provides production infrastructure where downtime directly impacts the business.

Processing Integrity (PI1)

Covers data processing accuracy and completeness. Relevant when the vendor performs calculations, data transformations, or automated decision-making on your data.

Confidentiality (C1)

Covers controls over data classified as confidential: encryption, access restrictions, and secure disposal. Required if the vendor handles trade secrets, source code, financial models, or other sensitive IP.

Privacy (P1–P8)

Covers personal information collection, use, retention, disclosure, and disposal. Required if the vendor processes PII subject to GDPR, CCPA, or state privacy laws.

A vendor’s SOC 2 may cover only Security and exclude Availability and Confidentiality entirely. 

If your primary concern is whether this vendor will take down your production environment or whether their employees can read your confidential data, the SOC 2 report provides no assurance on either question.

Before accepting any SOC 2 report:

• Confirm which criteria are in scope
• Map them to your actual risk exposure
• Escalate or supplement if critical areas are missing

How to Read a SOC 2 Report 

When you receive a SOC 2 report, read these four sections before anything else: 

Section 1: The auditor’s opinion

An unqualified opinion means controls operated effectively — a clean report. A qualified opinion means the auditor found material exceptions, such as one or more controls not operating as designed, during the audit period.

A qualified opinion does not automatically disqualify a vendor. Read why it is qualified and assess whether the exceptions affect your specific risk. 

For example, a deviation in change management approval for three low-risk deployments is different from a deviation in access deprovisioning for 60 days after employee termination.

Section 2: The management description of the system

This tells you exactly which systems, services, and infrastructure components are in scope. 

A vendor with 12 products may have scoped only three into the SOC 2. If the product you actually use is not listed in this section, the report provides zero assurance for your use case. Review the system description before treating the report as valid coverage.

Section 3: CUECs (Complementary User Entity Controls)

CUECs are controls that the vendor’s report assumes you have implemented on your side. They are your responsibility and not the vendor’s. Common examples are:

• Enforcing MFA on all user accounts that access the vendor’s platform
• Classifying data before transmission to the vendor
• Maintaining your own incident response procedures
• Restricting which internal users can access the vendor system

Here is why CUECs create a security gap. The vendor’s SOC 2 says “access to the platform is restricted to authorized users.” 

The CUEC appendix says “the user entity is responsible for enforcing MFA on all accounts.” If your organization has not enforced MFA, the vendor’s access control assurance is partially void for your organization. The auditor tested the vendor’s side. Nobody tested yours.

Many GRC platforms ingest SOC reports but do not automatically extract or track CUECs. Review this section manually and map each CUEC to your internal control environment.

Section 4: Test results and exceptions

Look for deviations — instances where a control did not operate as designed during the audit period. Read the management response for each exception to understand whether it was a one-time processing error or a systemic gap that was identified too late.

Suggested read: Full Guide to SOC 2 Compliance Checklist

Bridge Letters, Stale Reports, and the Coverage Gap Problem

A bridge letter is a management representation letter that a vendor provides to cover the period between the end of their SOC 2 audit window and the present. 

SOC 2 Type II reports cover a specific audit period. If a report ended December 31, 2025, and it is now September 2026, the report is nine months stale. The bridge letter is what vendors provide to cover that gap.

The letter is signed by management and states that no material changes have occurred and that controls have continued to operate effectively. Its practical value is limited but not zero. A knowingly false bridge letter creates legal exposure for the signing executive. 

Operational guidelines for accepting bridge letters

• Gaps under three months: Accept with standard documentation. Low additional risk.
• Gaps of three to six months: Require a documented risk acceptance from the appropriate authority in your organization.
• Gaps exceeding six months: Trigger re-assessment or include a contractual requirement for the vendor to provide the next report on an agreed schedule.

Bridge letters are a widely accepted but unregulated practice. No AICPA standard governs their format, content, or acceptable duration.

What to ask any vendor whose report is stale: “When does your next audit period end? When is the report expected to be issued? Can you provide a bridge letter signed by your CISO or equivalent?”

What Recent Breaches Reveal About SOC 2 Assurance Limits 

Three of the most damaging SaaS security incidents in 2022 and 2023 — LastPass, Okta, and Twilio — occurred at organizations that held active SOC 2 Type II certifications.

• LastPass (2022): A developer endpoint was compromised, followed by cloud storage access that exposed encrypted customer vaults. LastPass held SOC 2 Type II at the time. The attack vector, a developer’s personal device used to access production secrets, was outside the audited control environment.
• Okta (2022 and 2023): The January 2022 Lapsus$ intrusion exploited a support contractor. The October 2023 breach compromised a support case management system, enabling downstream access to files for MGM Resorts, Caesars Entertainment, and Cloudflare. Okta held SOC 2 Type II throughout. The CISA Advisory AA23-040A documented the Lapsus$ tactics used against Okta.
• Twilio (2022): A phishing and social engineering attack compromised Twilio’s internal systems, affecting 130+ downstream organizations, including Signal and Authy. SOC 2 Type II certified. The attack used employee credentials obtained via SMS phishing—a social engineering vector that audit sampling services does not reliably detect.

SOC 2 measures control effectiveness within scope, but it does not eliminate exposure outside that scope or across human attack vectors. 

How SOC 2 Maps to ISO 27001, NIST CSF 2.0, and CIS Controls

SOC 2 Trust Services Criteria map directly to controls in ISO 27001 Annex A, NIST Cybersecurity Framework 2.0, and CIS Controls v8. 

Organizations pursuing multiple frameworks can leverage SOC 2 evidence across compliance programs, reducing duplicate audit effort. 

The mapping also helps practitioners evaluate whether a vendor’s SOC 2 addresses the control areas required by their own framework.

SOC 2 and NIST CSF 2.0

SOC 2 CC6 (Logical Access) maps to NIST CSF 2.0 PR.AA (Identity Management and Access Control). SOC 2 CC7 (System Operations) maps to DE.CM (Continuous Monitoring). SOC 2 CC8 (Change Management) maps to PR.IP (Information Protection Processes). 

The GV.SC supply chain risk management function introduced in CSF 2.0 directly cites third-party audit reports — including SOC 2 Type II — as a mechanism for satisfying GV.SC-04 through GV.SC-09 for IT vendors.

SOC 2 and ISO 27001:2022

SOC 2 CC6 maps to ISO Annex A.8 (Technological Controls — access control, authentication). SOC 2 CC7 maps to Annex A.8.16 (Monitoring activities). CUECs map directly to Annex A.5.19 through A.5.22 (Supplier relationships). ISO 27001 certification auditors can accept SOC 2 Type II as evidence for A.5.22 compliance when vendor assurance is the objective.

SOC 2 and CIS Controls v8

SOC 2 TSC broadly maps to CIS Control 15 (Service Provider Management). Safeguards 15.5 (periodic review of audit results) and 15.7 (documentation of security commitments) are directly satisfied by a SOC 2 Type II report. CIS Controls v8.1 updated the language in Safeguard 15 in June 2024.

SOC for Cybersecurity and SOC for Supply Chain — What Is Coming Next

Beyond SOC 1 and SOC 2, the AICPA has introduced two newer examination types: 

• SOC for Cybersecurity: Assesses an organization’s entire cybersecurity risk management program. SOC 2 is service-scoped, but SOC for Cybersecurity is entity-scoped. It is useful for organizations that need to report on their overall security posture to board-level stakeholders.
• SOC for Supply Chain: Assesses controls relevant to producing and distributing goods — manufacturing integrity, supply chain security, and production controls. Relevant for manufacturing, critical infrastructure, and organizations where physical supply chain integrity is a material risk. NIST SP 800-161 Rev 1 (C-SCRM) and NIST CSF 2.0’s GV.SC function reflects the regulatory pressure driving interest in this framework.

Neither framework has achieved the ubiquity of SOC 2 procurement. Unless your customers or regulators specifically request them, SOC 2 Type II remains the priority for IT and cloud service providers. 

For compliance programs being planned for 2026 through 2028, however, SOC for Cybersecurity is worth tracking as board-level demand for entity-wide security assurance continues to grow.

Conclusion

SOC reports are not compliance checkboxes. They are evidence artifacts with specific audiences, specific scopes, and specific validity windows.

Getting the report type wrong leaves your compliance program with a structural gap that auditors, regulators, and breaches will eventually expose. 

Getting the right report but failing to read it properly, skipping the system description, ignoring CUECs and accepting a stale report without a bridge letter creates the same gap with extra paperwork.

To manage vendor risk effectively, organizations must treat SOC reports as the starting point of due diligence and not the end.

If you are building or managing a compliance program that includes SOC 1, SOC 2, or both — whether for your own organization or for your vendor roster — the depth of that program matters more than the number of certifications in your file.

Network Intelligence has run hundreds of SOC engagements across BFSI, healthcare, and technology, and we own the outcome. 

Our platform’s agentic AI, Transilience, automates evidence collection and audit readiness to turn SOC 2 assessments from a one-time certification into an ongoing operational posture.

Talk to a compliance specialist today to get your SOC 2 assessment.