Category: Assessment and Due Diligence

SOC 2 Report

Also known as: SOC 2, Service Organization Controls 2 Report, SOC 2 Type 1, SOC 2 Type 2

Simply put

A SOC 2 report is an independent attestation that examines a service organization's controls related to one or more Trust Services Criteria: security, availability, processing integrity, confidentiality, and privacy. It is produced by an external party who evaluates whether those controls are suitably designed and, in some cases, operating effectively. Despite common usage, a SOC 2 is a report rather than a certification, and it does not by itself guarantee that an organization is secure or compliant.

Formal definition

A SOC 2 report is an independent attestation examining a service organization's controls mapped to one or more of the five Trust Services Criteria: Security (the Common Criteria), Availability, Processing Integrity, Confidentiality, and Privacy. A Type 1 report addresses the design of controls as of a point in time, while a Type 2 report evaluates both the design and the operating effectiveness of controls over a defined period. Practitioners should treat a SOC 2 as an attestation report scoped to the criteria the service organization selected, not a certification, and should note its limitations: the scope may exclude criteria not chosen (for example, a security-only report addresses neither privacy nor processing integrity), a Type 1 reflects only a single point in time and can become stale, and the report covers the systems and control boundary defined by the service organization rather than the assessing party's own environment. Reviewing the report's scope, applicable Trust Services Criteria, reporting period, and any noted exceptions is typically necessary before relying on it for third-party assurance.

Why it matters

For third-party assurance, a SOC 2 report is one of the more widely requested pieces of evidence when evaluating a service organization's control environment across the Trust Services Criteria of security, availability, processing integrity, confidentiality, and privacy. It offers an independent attestation rather than a self-reported questionnaire, which is why many programs treat it as a higher-quality input than a vendor's own claims. That distinction matters because independent examination reduces reliance on unverified attestation, though it does not replace the assessing organization's own risk judgment.

Who it's relevant to

Third-Party Risk and Vendor Management Teams

These teams frequently request SOC 2 reports during onboarding and periodic review. Their value depends on reading the scope, criteria, reporting period, and noted exceptions rather than accepting the report as a certification or a guarantee of security or compliance.

Security and Compliance Assessors

Assessors use SOC 2 reports as independent attestation evidence about a service organization's controls, which is stronger than self-reported questionnaires. They should distinguish design-only Type 1 reports from Type 2 reports that also address operating effectiveness over a period, and account for a report becoming stale over time.

Procurement and Contract Owners

Procurement professionals often set SOC 2 evidence as a condition of engagement. Understanding that a security-only report does not cover privacy or processing integrity helps ensure the required criteria match the risks of the service being contracted.

Service Organizations Being Assessed

Vendors that undergo SOC 2 examinations choose which Trust Services Criteria to include and define the system boundary. Being clear that the resulting report is an attestation rather than a certification, and disclosing scope and exceptions transparently, supports realistic reliance by their customers.

Inside SOC 2

Auditor's Opinion

An independent CPA firm's opinion on whether the service organization's controls are suitably designed (Type I) and, for Type II, operating effectively over a defined review period. The opinion may be unqualified, qualified, adverse, or a disclaimer, and readers should examine which was issued rather than assuming a clean result.

Management's Assertion

A statement by the service organization's management describing its system and asserting that the described controls are fairly presented and, where applicable, operating effectively. This is a self-representation that the auditor evaluates, not itself independent verification.

System Description

A narrative describing the boundaries of the system covered, including services, infrastructure, software, people, procedures, and data. The scope defined here determines what the report does and does not cover, so relevant systems can fall outside the examined boundary.

Trust Services Criteria

The criteria against which controls are evaluated, spanning Security (the common criteria, typically always included) and optionally Availability, Processing Integrity, Confidentiality, and Privacy. A report addresses only the categories selected in scope; for example, a Security-only report does not speak to Privacy or Availability.

Description of Controls and Tests (Type II)

In a Type II report, a detailed listing of the controls, the auditor's tests of those controls, and the results including any exceptions or deviations identified during the review period.

Complementary User Entity Controls (CUECs)

Controls the report assumes the customer organization will implement on its own side for the overall control objectives to be met. Effective use of a SOC 2 report requires assessing whether these customer-side controls are actually in place.

Subservice Organizations

Third parties used by the service organization, addressed via the carve-out method (excluded from the description) or the inclusive method (included). Carve-outs can leave gaps in visibility into downstream (fourth-party) controls.

Common questions

Answers to the questions practitioners most commonly ask about SOC 2.

Is a SOC 2 report a certification?

No. A SOC 2 report is not a certification. It is an attestation report issued by a licensed CPA firm expressing an opinion on a service organization's controls relevant to one or more Trust Services Criteria. Unlike a certification, it does not confer a pass/fail credential or a certificate against a defined standard; instead, it presents the auditor's opinion, a description of the system, and, in a Type 2 report, the results of testing over a period. Treating it as a certification overstates what the report conveys.

Does a SOC 2 report cover all types of third-party risk?

No. A SOC 2 report is scoped to controls relevant to the selected Trust Services Criteria (such as security, and optionally availability, processing integrity, confidentiality, or privacy). It does not, on its own, address financial, operational, geopolitical, or ESG risk, nor does it necessarily cover every system, product, or business unit of the service organization. Reviewers should confirm the scope described in the report rather than assuming it addresses the full range of risks associated with a vendor relationship.

How should we tell whether a vendor's SOC 2 report actually covers the service we use?

Review the system description and scope section to confirm the specific systems, services, and locations covered, and check that they match the service you consume. A report may cover only part of a vendor's environment. Confirm which Trust Services Criteria were included, since a security-only report will not speak to availability, confidentiality, or privacy controls that may matter to your use case.

What is the difference between a Type 1 and a Type 2 report for our assessment purposes?

A Type 1 report addresses the design of controls at a point in time, while a Type 2 report addresses both the design and the operating effectiveness of controls over a period. Many programs prefer a Type 2 report for ongoing assurance because it reflects whether controls functioned over time; a Type 1 report indicates only that controls appeared suitably designed as of a specific date.

How do we handle the reporting period and gaps between report dates?

Note the period covered by a Type 2 report and the time elapsed since it ended, as a report reflects only the period examined and can become stale. Where there is a gap between the end of the reporting period and your review, some programs request a bridge or gap letter from the vendor addressing whether material changes occurred, though such letters are typically management representations rather than independently tested assurance.

What should we do with exceptions noted in the report and the complementary user entity controls?

Read the auditor's testing results for noted exceptions or qualifications and assess their relevance to your risk tier, rather than treating an unqualified opinion as the only signal. Also review the complementary user entity controls, which are controls the report assumes your organization will implement; the report's conclusions may depend on those controls being in place on your side, so they should be mapped to your own control environment.

Common misconceptions

A SOC 2 report is a certification confirming the organization is secure.

A SOC 2 report is an attestation report expressing an auditor's opinion against selected Trust Services Criteria; it is not a certification and confers no pass/fail badge. The value depends on the type, the scope, the criteria selected, the review period, and any noted exceptions or qualified opinion.

A Type I and a Type II report provide equivalent assurance.

A Type I addresses the suitability of control design at a point in time, while a Type II also addresses operating effectiveness over a review period. A Type I says nothing about whether controls actually functioned over time, and both become stale as time passes since the report date or period end.

A SOC 2 report covers all forms of third-party risk.

A SOC 2 report is oriented toward controls relevant to the selected Trust Services Criteria (often information security) and does not address financial viability, geopolitical, operational resilience, or ESG risk. Its coverage is further bounded by the system description, so in-scope assurance may not extend to all services a customer relies on.

Best practices

Confirm the report type (Type I versus Type II) and, for Type II, verify the review period aligns with the timeframe you need assurance over and is recent enough to remain relevant.

Read the auditor's opinion in full to determine whether it is unqualified or contains qualifications, exceptions, or a disclaimer, rather than treating any report as a clean result.

Check that the system description and selected Trust Services Criteria actually cover the services and risks relevant to your relationship, noting any systems or criteria that fall outside the examined scope.

Review the Complementary User Entity Controls and assess whether your organization has implemented the controls the report assumes on the customer side.

Identify how subservice organizations are treated (carve-out versus inclusive) and pursue separate assurance for downstream parties where carve-outs create visibility gaps.

Treat the report as point-in-time evidence within ongoing monitoring, requesting refreshed reports on a defined cadence and supplementing with other due diligence rather than relying on it as a standalone or lasting guarantee.