SOC 225 April 2026 7 min read

SOC 2 Subservice Organizations: How to Handle Vendors

SOC 2 requires you to account for subservice organizations in your system description. Learn how to document vendor controls, obtain SOC reports, and satisfy CC9.2.

Key Takeaways

Subservice organizations are vendors whose services are part of your system boundary and whose controls you rely upon to meet your own SOC 2 commitments.
CC9.2 requires that you identify, assess, and manage risks from subservice organizations on an ongoing basis.
Your system description must disclose subservice organizations and indicate whether you are using the carve-out or inclusive method to account for their controls.
The carve-out method (most common) identifies the subservice organization and states that users must obtain their SOC 2 report separately.
Obtain and review SOC 2 reports from critical vendors at least annually — the review must be documented to satisfy CC9.2.

In this guide

What Is a Subservice Organization
Carve-Out vs Inclusive Method
System Description Requirements
CC9.2 Requirements
Obtaining and Reviewing SOC Reports
Complementary Subservice Organization Controls
Evidence Auditors Collect

What Is a Subservice Organization

A subservice organization is a vendor or third party that provides services to your organization that are part of your system — meaning your ability to meet your SOC 2 commitments depends in part on the controls operated by that vendor. The classic example is AWS: your system runs on AWS infrastructure, and AWS's physical security, network controls, and data center availability are not in your direct control but are fundamental to your security and availability posture.

Other common subservice organizations for SaaS companies include: identity providers (Okta, Azure AD) used to enforce authentication for your application, database services (MongoDB Atlas, PlanetScale), CDN providers (Cloudflare, Fastly), payment processors (Stripe, Braintree), and customer support platforms (Zendesk, Intercom) that store customer data.

Not every vendor is a subservice organization. A subservice organization specifically provides services that support the direct delivery of your system to your customers and that you rely on to meet Trust Service Criteria commitments. A marketing email vendor used only for internal communications is not a subservice organization. A transactional email provider that delivers password reset emails to your customers is a subservice organization (it is part of your authentication system).

Carve-Out vs Inclusive Method

When including subservice organizations in your SOC 2 report, you choose between two methods. The carve-out method acknowledges that the subservice organization's controls are not included in the audit scope and directs readers to obtain the subservice organization's own SOC 2 report for those controls. The inclusive method incorporates the subservice organization's controls into your audit scope — your auditor tests those controls directly.

The carve-out method is used in almost all SOC 2 engagements. AWS, Okta, Stripe, and other major SaaS vendors publish their own SOC 2 reports, so it is logical to reference their reports rather than having your auditor re-test AWS's physical security. The carve-out method acknowledges the dependency while directing customers to the authoritative source for the vendor's controls.

The inclusive method is rare and typically used when the subservice organization is a closely affiliated entity (a parent company, a shared service center) that does not have its own SOC 2 report and whose controls are sufficiently within your influence to be included in scope. Most standalone SaaS companies will never use the inclusive method.

System Description Requirements

Your SOC 2 system description — Section 3 of the final report — must disclose all significant subservice organizations and identify the method used to account for their controls. A typical system description disclosure: "The Company uses Amazon Web Services (AWS) for cloud infrastructure hosting. The Company applies the carve-out method for the controls provided by AWS. Users of this report should obtain and read the AWS SOC 2 Type II report to understand the controls operated by AWS that are relevant to their security requirements."

List each significant subservice organization with: the name of the provider, the services provided, the nature of the controls relied upon, and the accounting method (carve-out). Your auditor will help you draft this section. Be comprehensive — missing a significant subservice organization from the system description is a finding that your auditor or a knowledgeable reader of the report will identify.

For each carve-out subservice organization, your system description should also include a "Complementary Subservice Organization Controls" section describing the controls you rely on the subservice organization to have in place. This section sets expectations that must be validated through their SOC 2 report review.

CC9.2 Requirements

CC9.2 requires that the entity assesses and manages risks from subservice organizations on an ongoing basis. This means: identifying subservice organizations before granting them access to in-scope systems; assessing their security posture (typically by obtaining and reviewing their SOC 2 report or security questionnaire); establishing contractual requirements (data processing agreements, security addendums); monitoring for changes in their risk profile (reviewing their updated reports annually, monitoring for security incidents at the vendor); and maintaining a vendor risk register.

The "ongoing basis" language is important — CC9.2 is not satisfied by a one-time assessment at onboarding. You must establish a periodic review cadence and document that reviews are occurring. For Tier 1 vendors (subservice organizations), annual review of their SOC 2 report is the standard. Document the review: date, reviewer, report reviewed, scope of the vendor's report, any gaps between their report and your reliance, and action items.

CC9.2 also requires that you assess risks before onboarding new subservice organizations — not after granting access. Build vendor assessment into your procurement workflow as a required step before any new vendor receives access to in-scope systems or data.

Obtaining and Reviewing SOC Reports

Obtaining SOC 2 reports from major cloud infrastructure providers is straightforward. AWS Artifact (the AWS compliance portal) provides their SOC 2 reports on demand at no cost — download the report directly from the portal and retain a copy in your vendor evidence library. GCP, Azure, Okta, Salesforce, Stripe, and most major SaaS vendors publish their SOC 2 reports through their compliance portals or upon NDA request.

Reviewing the report means actually reading the relevant sections — not just noting the report exists. Key review steps: verify the report period matches the period you are assessing; confirm the criteria in scope (Security, Availability, Confidentiality, etc.) are relevant to the services you are relying on; review the principal auditor's opinion (qualified or unqualified); read Section 4 (complementary user entity controls) to identify controls you are responsible for implementing; and note any exceptions in the auditor's test results.

Document your review. A brief summary note (2–3 paragraphs covering scope, opinion, exceptions, and CUECs) signed by the reviewer and filed in your vendor record satisfies the CC9.2 evidence requirement. A note that says only "reviewed Okta SOC 2 — looks fine" is less satisfying to an auditor than a structured review document.

Complementary Subservice Organization Controls

SOC 2 reports from subservice organizations include a section on Complementary User Entity Controls (CUECs) — controls that the vendor assumes their customers will implement for the overall control environment to be effective. For AWS, CUECs include: that customers will configure IAM roles and security groups appropriately; that customers will enable CloudTrail and AWS Config; and that customers will review their VPC and security group configurations for appropriateness.

You are responsible for implementing the CUECs identified by your subservice organizations. Your auditor will review the CUEC sections of each significant vendor's SOC 2 report and verify that the corresponding controls are in place in your environment. A CUEC that is not implemented is a gap in your control environment even though the control is nominally the vendor's.

Document which CUECs apply from each significant vendor and map them to controls in your own control framework. This mapping is evidence that you reviewed the vendor reports thoroughly and considered their implications for your control environment. AuditPath and similar compliance platforms typically include CUEC mapping as part of vendor management workflows.

Evidence Auditors Collect

For CC9.2 and subservice organization management, auditors request: (1) your vendor management policy and risk tiering methodology; (2) the current vendor register showing all significant vendors with tier classification; (3) SOC 2 reports (or equivalent) obtained for Tier 1 vendors, with documentation of when each was obtained and reviewed; (4) vendor review records showing structured review of each SOC 2 report; (5) data processing agreements or security addendums with significant vendors; and (6) new vendor onboarding records showing assessment occurred before access was granted.

The system description section of your SOC 2 report will name your significant subservice organizations — auditors use this as a checklist to verify that SOC 2 reports have been obtained for each. If your system description lists Stripe as a subservice organization but your vendor file has no Stripe SOC 2 report, the auditor will note this as an exception.

Annual review timing matters: a vendor's SOC 2 report should be reviewed within the 12 months preceding the audit. A Stripe SOC 2 report downloaded two years ago and never updated does not satisfy CC9.2 for the current observation period.

Frequently Asked Questions

Does every SaaS vendor we use count as a subservice organization?

No. A subservice organization is a vendor whose controls you rely upon to meet your SOC 2 commitments. Typically this means vendors that process customer data, provide authentication, or host production infrastructure. A vendor used only for internal purposes (e.g., a project management tool used internally with no connection to your production system or customer data) is not a subservice organization — it is a vendor subject to your general vendor management process under CC9.2.

What if AWS's SOC 2 report has exceptions?

AWS's SOC 2 report typically contains a small number of exceptions in a very large control set. Review each exception and assess whether it affects controls you rely on. If an exception is in a control area not relevant to your use of AWS (e.g., a physical access exception at a data center you don't use), document that it is not material to your reliance. If an exception affects a control you do rely on, document a compensating control you have implemented.

Can we use a SOC 3 report instead of a SOC 2 report for a vendor?

SOC 3 reports are publicly available summaries that confirm a SOC 2 audit was completed with a clean opinion, but they do not contain the detailed control descriptions, test results, or exception information needed for a meaningful review. For subservice organization management under CC9.2, you need the full SOC 2 Type II report. If a vendor offers only a SOC 3 or a certification but no full SOC 2 report, request a security questionnaire (SIG Lite) as an alternative.

Our key vendor just had a security breach. What do we need to do for SOC 2?

A security breach at a critical vendor is a trigger for an out-of-cycle CC9.2 assessment. Obtain a breach notification or incident disclosure from the vendor, assess whether the breach affected systems or data relevant to your SOC 2 scope, evaluate whether any compensating controls or access restrictions are needed, and document the assessment and your response. Update your vendor risk register. If the breach indicates a gap in the vendor's controls that your own controls cannot compensate for, consider whether the vendor relationship needs to change.

Do we need to list all our subservice organizations in the SOC 2 report?

You must list all significant subservice organizations — those whose controls are material to your ability to meet your Trust Service Criteria commitments. There is no requirement to list every SaaS tool your company uses. Work with your auditor to determine which vendors are significant enough to be named in the system description. For most SaaS companies, the list includes cloud infrastructure (AWS/GCP/Azure), identity provider (Okta/Azure AD), and 3–8 additional critical data processors.