Key Insights
SOC reports show up in nearly every vendor security review, but treating them as a simple trust signal can leave a security team exposed. A clean report can still hide gaps in scope, stale evidence, or controls the customer is expected to run.
For security, GRC, and third-party risk teams pursuing a report or evaluating one from a vendor, the value comes from knowing exactly what assurance it provides about a vendor's security posture and where that assurance stops.
Key Takeaways
- Each SOC report type answers a different security and risk question, and requesting the wrong one leaves third-party risk decisions without useful assurance.
- The audit lifecycle spans scoping, readiness, remediation, and fieldwork before a final report is issued, so the document reflects a structured evaluation of a vendor's control environment.
- Complementary user entity controls, carve-out gaps, and stale report periods limit how much a security team can rely on a clean auditor opinion.
- SOC reports support third-party risk management across financial services, healthcare, and data privacy contexts. Framework-specific cybersecurity and compliance obligations still apply.
What a SOC Report Is and Why It Matters
A SOC report is an independent assurance document issued by a licensed CPA (Certified Public Accountant) firm that evaluates the security, availability, and related controls a service organization has in place over defined systems and processes.
SOC Reports as Assurance on Security Controls
System and Organization Controls refers to a suite of assurance services that gives security and risk teams the information they need to assess risks tied to outsourced services, cloud providers, and SaaS vendors.
The output is an attestation report containing a professional opinion on whether a service organization's controls, including its cybersecurity controls, meet specified criteria. SOC 1 engagements fall under AT-C Section 320, while SOC 2 and SOC 3 examinations generally rely on AT-C Section 205 within the AICPA attestation framework.
An independent auditor issues the opinion, and the CPA firm must participate in an approved peer review program. This independence requirement gives SOC reports assurance weight that self-attestations and vendor-completed security questionnaires cannot match.
The Audiences That Use SOC Reports
For the service organization undergoing the audit, the report demonstrates to customers, prospects, and regulators that security and operational controls have been independently verified.
Procurement and security teams evaluating new vendors use SOC reports to confirm that a provider's control environment meets their risk tolerance before signing a contract. Internal auditors and GRC teams map the vendor's controls documented in the report against their own risk registers and security frameworks. The mapping identifies gaps that require compensating controls on the customer side.
Compliance and third-party risk managers often use SOC reports as part of vendor risk reviews and audit documentation, particularly in regulated industries such as financial services and healthcare. A single SOC report can replace lengthy security questionnaires and reduce the duplicated effort that slows vendor onboarding and renewal cycles.
SOC Reports in Vendor Due Diligence and Trust Decisions
The Verizon 2025 DBIR found that the percentage of breaches involving a third party doubled year over year, making vendor assurance a central concern for security teams. SOC reports give security and risk teams a standardized way to evaluate whether a vendor's control environment meets their risk tolerance.
Within a broader third-party risk management (TPRM) program, SOC reports sit alongside contractual security requirements, penetration test summaries, and on-site assessments.
SOC Report Types and What Each One Covers
Different SOC report types exist to answer different assurance questions, so matching the report type to the security or compliance question matters as much as the opinion itself.
SOC 1 and Internal Control Over Financial Reporting
A SOC 1 report evaluates controls at a service organization that are likely relevant to user entities' internal control over financial reporting (ICFR). Governed by SSAE 18 (AT-C Section 320), SOC 1 reports target payroll processors, payment processors, loan servicers, and plan recordkeepers. Unlike SOC 2, SOC 1 reports have no pre-specified AICPA criteria; the service organization develops control objectives specific to its own system.
These restricted-use documents are shared only with user entities and their financial statement auditors and commonly support SOX audit requirements. Security teams encounter SOC 1 indirectly when access controls, change management, and segregation of duties on financial systems fall in scope.
SOC 2 and the Trust Services Criteria
A SOC 2 report is a cybersecurity-focused SOC report. It examines controls relevant to security, availability, processing integrity, confidentiality, or privacy, as defined by the AICPA's 2017 Trust Services Criteria with revised points of focus issued in 2022.
The Security criterion (the common criteria) is required and forms the cybersecurity backbone of the report. It maps to the COSO Internal Control framework and covers logical and physical access, system operations, change management, risk mitigation, and incident response.
Organizations add optional criteria based on their service commitments: Availability for SaaS resilience, Processing Integrity for transaction accuracy, Confidentiality for sensitive business data, and Privacy for personal information.
SOC 3 as the General-Use Version of SOC 2
A SOC 3 report covers the same Trust Services Criteria as a SOC 2 but strips out the detailed test procedures and results, leaving only the auditor's opinion. SOC 3 reports are general-use documents that can be freely distributed, while SOC 1 and SOC 2 reports are restricted-use and typically shared under NDA.
Vendors often post SOC 3 reports on their trust centers as a public security signal for prospects who need only general assurance. Security teams that need to evaluate specific controls, review exceptions, or confirm scope coverage need a SOC 2.
SOC for Cybersecurity and SOC for Supply Chain
SOC for Cybersecurity evaluates an organization's enterprise-wide cybersecurity risk management program against the AICPA's description criteria. Where SOC 2 examines controls over a specific service or system, SOC for Cybersecurity addresses the full entity's security posture, including governance, risk assessment, and threat identification.
SOC for Supply Chain addresses controls within production, manufacturing, or distribution systems, including the operational technology (OT) environments that support them.
Organizations pursue SOC for Cybersecurity when customers, boards, or regulators need full-enterprise assurance, and SOC for Supply Chain when production or distribution integrity is the primary concern.
Type I vs. Type II in a SOC Report
Both SOC 1 and SOC 2 are issued in two forms, and the distinction determines how much confidence a security team can place in the report's findings.
Point-in-Time Design Assessment
A Type I report evaluates whether controls were suitably designed as of a specific date. The auditor performs walkthroughs of the control environment, reviews security policies and procedures, interviews process owners, and confirms that controls exist and are constructed to meet their stated objectives. The auditor performs design work only and leaves operating effectiveness untested over time.
Organizations commonly begin with a Type I because it validates control design before a longer observation period and surfaces design gaps that can be corrected before a Type II engagement begins.
Period-of-Time Operating Effectiveness
A Type II report evaluates both the design and the operating effectiveness of controls over a defined period. The auditor selects samples from across the observation window and tests whether controls functioned consistently throughout. Where a Type I confirms that a password policy requires a minimum length, a Type II verifies that the system enforced that requirement across account changes and provisioning events during the observation period.
Sampling methodology varies by control type and population size; automated controls may be tested once if the auditor confirms no changes occurred, while manual controls such as access reviews or incident response procedures require broader sampling across the period.
Reader Expectations for Type II Evidence
Type II reports evaluate control design and operating effectiveness over time, which can provide higher assurance in an ongoing vendor relationship.
A Type I confirms that a control was designed correctly at a single point, but it says nothing about whether that control operated without failure across the contract period, the window where breaches and control failures actually occur.
Financial statement auditors relying on SOC 1 reports for ICFR purposes specifically need Type II evidence because it demonstrates that controls functioned consistently throughout the review period. Security teams should set the same bar for SOC 2.
What Is Inside a SOC Report?
Most SOC reports follow a familiar structure, and understanding that structure helps security reviewers separate the auditor's opinion from management's descriptions and supplemental material.
The Independent Service Auditor's Report
The opinion takes one of four forms: unqualified, qualified, adverse, or disclaimer. An unqualified opinion means exceptions did not undermine the overall effectiveness of the control environment. Reviewers should check whether the opinion covers the full examination period, confirm which Trust Services Criteria were included, and verify that the scope matches the services they depend on. A qualified opinion warrants direct follow-up with the service organization to understand the specific control failures or matters excluded.
Management's Assertion
Written by the service organization's management, this part of the report contains their formal claim that the system description is accurate, that controls are suitably designed, and, for Type II reports, that controls operated effectively. The assertion identifies whether subservice organizations (such as cloud infrastructure providers) are handled through the carve-out method or the inclusive method and acknowledges the existence of complementary user entity controls. Reviewers should confirm the assertion is present and consistent with the auditor's opinion. The assertion also establishes the examination period, so reviewers should verify that the dates align with their own review window.
The System Description
The system description covers the environment under examination: its scope boundaries, infrastructure, people, processes, and any subservice organizations involved. A vendor may offer multiple products but scope only some into its SOC report, which means the services a customer actually depends on may not be covered at all.
Reading the system description carefully is the only way to confirm that in-scope services match the ones under contract. Look for the list of data center locations covered, the specific applications or platforms included, and any explicit exclusions. Subservice organizations are identified here along with whether each is carved out or included.
Tests of Controls and Results
The tests-of-controls portion presents the procedures performed, the results of those tests, and any exceptions identified. Exceptions can exist alongside an unqualified overall opinion. Security reviewers should focus on the nature and frequency of exceptions, whether management provided responses or remediation plans, and whether exceptions cluster around specific control domains.
Patterns of repeated exceptions in access management, change control, or vulnerability management may indicate systemic weaknesses that a single unqualified opinion does not fully convey.
Other Information and Its Limits
When included, the supplemental information portion contains additional context provided by the service organization, such as planned security improvements, additional service descriptions, or future control commitments.
This material falls outside the audit and the auditor's opinion. Treating supplemental content as though it carries the same weight as the auditor-tested portions of the report can lead relying parties to overestimate the assurance a report actually provides.
How SOC Reports Are Produced
A SOC report is produced through a staged audit process that begins with scope decisions and ends with formal issuance.
Scoping and Readiness Assessment
The process begins with jointly defining the examination boundaries: which systems, services, locations, and criteria are in scope. For SOC 2, this includes selecting which of the five Trust Services Criteria apply based on the organization's service commitments. A readiness assessment follows, comparing existing security controls against the applicable criteria to surface gaps before the formal examination begins.
The readiness assessment provides the organization with an understanding of the controls and processes to be covered, the evidence to be requested, and the procedures the auditor will perform during fieldwork. Implementing fixes directly would jeopardize auditor independence for the firm performing the readiness assessment, since a service auditor cannot objectively audit their own work.
Control Implementation and the Observation Period
After the readiness assessment, the organization addresses identified gaps by documenting security policies, implementing technical controls such as MFA, logging, and access reviews, and establishing evidence collection processes.
Because the AICPA has not defined a prescriptive list of required controls, specific remediation work is guided by gap analysis findings and the agreed scope. For Type II reports, controls must then operate over a defined observation period before the auditor can test their operating effectiveness.
Fieldwork, Exceptions, and Final Issuance
During fieldwork, the auditor conducts walkthroughs, interviews security and IT personnel, and executes testing procedures against sampled evidence. The results identify any exceptions. For Type II engagements, testing spans the full observation period and includes samples from across that window.
When exceptions arise, the service organization may have an opportunity to remediate before the report is finalized, though the timing and the auditor's judgment determine whether remediated items still appear. After testing concludes, management reviews the system description and assertion for accuracy.
How to Review and Rely on SOC Reports
A SOC report only provides value if the reviewer knows where its assurance starts and stops.
Scope, Period, and Auditor Opinion
Three questions determine whether a report applies to your situation. Does the report cover the services you actually use? A report scoped to one product line may say nothing about the service you depend on. Does the period align with your review window? A report period that ended too long ago provides limited current assurance about the vendor's present security posture. Is the opinion unqualified?
A qualified or adverse opinion warrants direct follow-up to understand the specific control failures that affected the auditor's conclusion. Answering these questions before reading deeper prevents reliance on an inapplicable report.
Subservice Organizations and Carve-Out Risk
Many service organizations rely on vendors of their own, especially cloud and infrastructure providers. Under the inclusive method, the subservice organization's controls are described and tested within the report. Under the carve-out method, the subservice organization's controls are excluded from the scope of testing.
A cloud infrastructure provider carved out of a SaaS vendor's SOC 2 means the relying party may not receive auditor-tested evidence about the underlying infrastructure security within the SaaS vendor's report and may need separate assurance from the cloud provider.
The relying party must independently assess carved-out subservice organizations through its own due diligence, which may include requesting the subservice organization's own SOC report directly.
Complementary User Entity Controls
CUECs are controls the service organization expects its customers to implement for the overall system to operate securely as described. A clean opinion on a vendor's SOC report leaves your organization's CUEC implementation for you to validate; common CUECs include enforcing MFA on customer-managed accounts, configuring role-based access correctly, and monitoring administrative activity.
CUECs typically appear toward the end of the system description in Section III. Security teams should inventory every CUEC listed in the report, map each one to their own existing controls, verify implementation, document the mapping as evidence for their own auditors, and flag any unimplementable CUECs as residual risks requiring compensating controls.
Bridge Letters, Stale Reports, and Reliance Gaps
When a SOC report's period ends before the next report is issued, some service organizations offer bridge letters to cover the gap. These are management assertions and lack independent testing results or an auditor opinion. A bridge letter lacks the independent verification that defines a SOC report.
A current SOC report is needed for that level of assurance. Verifying the report period dates against your review window should be a standard step in vendor intake and renewal.
Where SOC Reports Fit in Compliance and Risk Management
SOC reports support security due diligence and oversight across multiple compliance contexts. Framework-specific obligations still apply.
SOC Reports in Third-Party Risk Management
The IBM breach report highlights the cost of third-party vendor and supply chain compromise breaches, which makes structured vendor assurance a core security function. SOC reports give risk teams independently verified evidence that reduces reliance on self-reported security questionnaires.
Within a TPRM program, SOC reports provide a repeatable assessment mechanism across onboarding, periodic reviews, and contract renewals.
HIPAA, PCI DSS, and GDPR Context
A SOC 2 report scoped to include the Privacy and Confidentiality criteria provides documented evidence of processor-level security controls relevant to HIPAA business associate oversight. Privacy criteria in the AICPA framework can align with GDPR requirements. This alignment supports Article 28 processor due diligence obligations for data protection.
For PCI DSS, a SOC 2 can supplement a PCI-specific Attestation of Compliance or Report on Compliance, though it does not replace them. The PCI Security Standards Council confirms that merchants and service providers must manage and monitor the PCI DSS compliance of all associated third-party service providers with access to cardholder data.
FFIEC, OCC, and Financial Services Oversight
Financial regulators expect banks to verify that third-party service providers maintain adequate security and operational controls, with the interagency guidance in FIL-29-2023 establishing the governing framework. SOC 1 reports are commonly used to assess service providers that affect financial reporting, such as core banking processors and loan servicers.
SOC 2 reports address cybersecurity and operational resilience at those same providers. The OCC's 2024 Cybersecurity and Financial System Resilience Report notes the OCC's supervision of financial institutions and, when applicable, third-party service providers.
Reading SOC Reports With Clearer Expectations
SOC reports are most useful when security and risk teams read them as bounded assurance documents with defined scope, period, and shared control responsibilities. The strongest review starts with scope, period, opinion, and CUEC ownership, then weighs those details against the threat model and decision at hand.
That approach leads to better reliance decisions and fewer surprises when security, compliance, and audit teams need the report to answer a specific question about a vendor's defenses.
