SOC 2 subservice organizations: which method fits your cloud and vendors
If your platform runs on a cloud provider or depends on other third parties you do not control, you must decide how each one appears in your SOC 2. The carve-out method excludes the subservice organization's controls from your examination and lists them as complementary subservice organization controls (CSOCs). The inclusive method describes the subservice organization's services in your system description and brings its controls into the scope your auditor tests. The choice is driven by your provider's own SOC report, the services you actually use, and how much of each control you can see and evidence yourself.
Work through the decision in this order. First, list every subservice organization whose services support the system, including hosting, backup, support tooling and any self-hosted component your customers operate. Second, obtain each provider's current SOC report and check which controls it covers and which it leaves to customers. Third, for each CSOC, name the internal owner who monitors the provider's report, reviews exceptions and documents the carve-out in the system description. The AICPA's SOC 2 Report Walkthrough course covers inclusive versus carve-out reporting and CSOCs, and DC 200 requires you to disclose subservice organizations and their complementary controls in the description either way.
Keep the roles clear. Your organization owns its controls and the vendor oversight evidence under CC9.2. An implementation partner can prepare system descriptions, control inventories and vendor files, but it does not decide the scope or issue the report. Only the independent CPA firm issues the SOC 2 report. Confirm with that firm, before fieldwork, which method it expects for each provider, because a late switch can change the system description and the sample populations your team must produce.
Carve-out or inclusive: how each method changes the report
Under the carve-out method, the service organization excludes the subservice organization's controls and the services it performs from the scope of its own examination. The system description still identifies the subservice organization and describes the services it provides, but the auditor does not test the provider's controls as part of the service organization's engagement. Instead, the report lists complementary subservice organization controls (CSOCs): the controls the provider is expected to operate for the service organization's commitments to hold. Those CSOCs are what the reader must check.
- System description: The provider is named and its role is described, but its infrastructure and internal controls are outside the boundary of the tested system.
- CSOC listing: The service organization lists the controls it assumes the provider runs, mapped to the criteria they support, so readers can see the dependency.
- Auditor testing: The auditor tests the service organization's own controls over its use of the provider, such as configuration, monitoring and vendor oversight under CC9.2, not the provider's data center or platform controls.
- Provider SOC report: The provider's own SOC report is typically used to support the CSOCs and to inform vendor oversight, and it must be reviewed for exceptions and for the provider's own complementary controls.
- Fit: Carve-out tends to suit providers that already publish a current report and whose infrastructure the service organization cannot meaningfully test or influence.
Confirm with your CPA firm which CSOCs it expects you to list and how they must map to the criteria you selected.
Under the inclusive method, the subservice organization's controls relevant to the criteria are included within the scope of the service organization's examination. The system description covers the provider's services as part of the system, and the auditor tests the controls that operate at the provider. The service organization does not list those controls as CSOCs because they are part of the tested environment. The provider's cooperation, including access for the auditor and evidence in the auditor's requested format, becomes a practical dependency of the engagement.
- System description: The provider's relevant services and components appear as part of the system, so readers see the full path from customer data to the provider's infrastructure.
- CSOC treatment: Controls covered by the inclusive approach are tested directly rather than listed as complementary dependencies.
- Auditor testing: The auditor samples and tests provider-operated controls, which requires evidence from the provider, often in a form the provider has agreed to produce.
- Provider SOC report: The provider's report can still inform the work, but the auditor will need to assess whether it covers the controls and period in scope, and what gaps remain.
- Fit: Inclusive can suit cases where the service organization configures and operates significant parts of the provider's environment, or where readers expect a single end-to-end view.
Agree the provider's evidence obligations and timing in writing before fieldwork begins, because the report depends on them.
The AICPA staff FAQs, reported by the Journal of Accountancy in December 2020, include a question on whether management can use the carve-out method for a subservice organization in a SOC 3 report. A SOC 3 covers the same trust services categories as a SOC 2 in less detail and is a general use report that can be freely distributed. Because a SOC 3 is public-facing, the treatment of subservice organizations there matters to anyone who reads it as a summary of controls.
- Why the question arises: A SOC 3 is shorter than a SOC 2, so the treatment of CSOCs and of the provider's role must be stated clearly enough that readers are not misled.
- What to confirm: Ask your CPA firm whether carve-out is acceptable in your SOC 3 and how the provider's role should be described.
- Do not assume: Do not copy the SOC 2 treatment into a SOC 3 without checking current AICPA guidance and your firm's view.
- Customer communication: Trust pages and sales materials should reflect the same treatment as the report, so readers do not infer more coverage than the report gives.
- Records: Keep the written confirmation from your CPA firm with the engagement file.
Request the firm's written position on SOC 3 subservice treatment before you publish any SOC 3 report.
How to use a provider's own SOC report as evidence
A cloud provider's SOC report can support your own examination, but it does not cover your system or your controls. The cards below cover how to get the report, which parts apply to you, and what to check before you rely on it under the carve-out or inclusive method.
Obtain the report through AWS Artifact
AWS makes its SOC 1 and SOC 2 reports available to customers through AWS Artifact, and an NDA is required before you can review them. Plan for the NDA step early, because your auditor will expect to read the report itself rather than a summary. Confirm with AWS which report versions and periods are currently available in Artifact, since coverage changes over time.
Map the provider's CSOCs to your controls
The provider's report lists complementary subservice organization controls (CSOCs), which are controls the provider expects its customers, or the service organization itself, to operate. Under the carve-out method, your system description must name the provider and say which controls you monitor through its report. Build a table that matches each CSOC to a control in your own matrix and an owner who checks it.
Check the report period and scope
A provider report covers a specific period and a defined list of in-scope services. Compare those dates with your own observation period, and confirm that the services you run on, such as the regions, databases and managed components, appear in the scope. If the gap between the provider's period end and your period is not bridged, your auditor may ask for a bridge letter or additional evidence.
Split responsibility using the shared model
AWS lists physical and environmental controls as fully inherited by customers, patch management, configuration management and awareness and training as shared controls each party implements for its own scope, and zone security as a customer-specific control. Use this split to decide which controls your team must evidence directly. Treat any control the provider lists as customer-specific as entirely your responsibility.
Review exceptions and qualified opinions
Read the provider's testing results and any exceptions in its report, including deviations found in operating effectiveness testing. An exception on a control you depend on, such as access reviews or change logging in a managed service, may affect your own opinion or require a compensating control. Record how you reviewed each exception and what you did about it, because your auditor will ask.
Use the SOC 3 for public context only
A provider's SOC 3 report is a general use report that can be shared publicly, but it describes the trust services criteria at a higher level and omits the detailed test results. It can support a customer conversation or a trust page, yet it is not sufficient evidence for your auditor. Your auditor will still need the SOC 2 report under NDA and your own evidence for the controls you operate.
How CC9.2 vendor oversight works for subservice organizations
The sequence turns a subservice organization from a name on a list into a managed relationship, with a documented risk view, a named owner, reviewed assurance and an exit path that an auditor can test across the examination period.
Identify each subservice organization
Start from the system boundary and list every third party that performs part of the service, such as the cloud hosting provider, managed database or logging services, support tooling that touches customer data, and any contractor with production access. Record what each one does, which criteria its work touches and whether the organization will use the carve-out or inclusive method for it. The output is a subservice inventory approved by management and tied to the system description. An auditor will compare this inventory against the system description and the infrastructure diagrams, so gaps show up quickly.
Assess each vendor's risk
For each entry, assess the risk the vendor poses to the service commitments, considering the data it holds or processes, the access it has, its criticality to availability and how easily the work could be brought back in-house or moved. Set a risk rating and record the reasoning in a short assessment. The output is a dated risk assessment per subservice organization, linked to the CC3 risk register where the vendor risk is recorded. Auditors sample these assessments for the period and check that higher-risk vendors receive deeper review.
Assign a named owner
Name one accountable individual inside the organization for each subservice relationship. The owner holds the contract or service terms, receives the vendor's assurance reports, tracks issues and signs off on the review. Ownership should be written into the vendor register or responsibility matrix, not left to a shared mailbox. The output is a register showing owner, backup owner and the date of the last review. Auditors test this by asking who owns a sampled vendor and checking that the named person actually performed the review.
Obtain and review the vendor's assurance
Request the subservice organization's current SOC 2 or other independent assurance report, along with bridge letters where the report period does not cover the full period under review. Read the scope, the carved-out or included controls, the complementary subservice organization controls (CSOCs) and any exceptions. Map each CSOC to a control the organization runs itself, then record whether that control is in place. The output is a review memo per vendor showing the report period, exceptions, and the CSOC mapping. AWS, for example, makes its SOC reports available through AWS Artifact, where an NDA is required to review them, so confirm the access route for each provider.
Document exceptions and communication protocols
Record how the organization communicates with each vendor on security matters, including who the vendor notifies of incidents, service changes and control failures, and the route for raising exceptions in the vendor's controls. Agree the protocol in writing and log each exception with its impact on the organization's own controls and any compensating action. The output is an exception log and a communication matrix. Auditors sample exceptions to see whether they were escalated, assessed and closed, rather than accepted silently.
Assess vendor performance
At the frequency set in the vendor review policy, check the vendor's performance against the contractual service commitments and the organization's own expectations. Review availability reports, incident history, support responsiveness and any changes to the vendor's controls or location of data. Compare the results with the risk rating from the earlier step and update the rating if the picture has changed. The output is a dated performance review per vendor, signed by the owner. Confirm the review cadence with your own policy and the vendor contract, since the researched facts do not set one.
Address findings from the review
Where a review finds a gap, such as a missing CSOC control, an unresolved vendor exception or a service level miss, open a tracked remediation item with an owner and a target date. Agree with the vendor what it will change, or add a compensating control inside the organization's own environment. The output is a findings tracker showing each item, its status and its closure evidence. Auditors often follow a finding from the vendor review into the monitoring activities of CC4 to confirm it was corrected.
Define termination and exit
For each subservice organization, document the conditions under which the relationship would end, the data return or deletion steps, and the plan for moving the function to another provider or bringing it in-house. Confirm the contract includes the exit terms needed to carry them out. The output is an exit plan per critical vendor, reviewed when the risk rating changes. CC9.2 covers terminating relationships as part of managing vendor risk, so auditors look for evidence that the plan exists, has been reviewed and matches the contract.
Gaps that appear when the provider report does not match your period
A provider's SOC 2 report is only evidence for the period, region and services it actually covers. The cards below describe the mismatches that most often leave a subservice organization control without support in your own report, and what to check before the auditor does.
Provider report period ends early
If the provider's report period ends before your observation period starts, or leaves a gap between the two, the auditor has no provider evidence for those months. Compare both period end dates against your own observation window and list any uncovered months. Ask the CPA firm whether a bridge letter from the provider will be accepted for the gap, since bridge letter requirements vary by firm and are covered in the SOC 2 guides.
Report covers a different region or service
A provider report may cover a set of regions or services that differs from the ones your system uses. A managed database in a region not named in the report, or a service added after the report period, is not covered by that report. Check the system description in the provider report against your own architecture diagram, and confirm with the provider in writing which regions and services are in scope.
CSOC listed with no owner
Your system description may list a complementary subservice organization control (CSOC) that the provider expects you to run, such as reviewing its access reports or configuring its logging. If no person or team is named as the owner, the control will not operate and the gap will surface during fieldwork. Assign an owner, a frequency and evidence for every CSOC before the observation period starts.
Provider exception affects your controls
An exception in the provider's report, such as a failed access review or a late change approval, can affect the controls you rely on for your own system. Exceptions do not stay inside the provider's scope. Read each exception in the provider report and decide whether it touches a control you have carved out or included, then document how your own controls compensate or how the exception is disclosed.
Provider architecture changes after the report
A provider may change how a service is built, hosted or administered after its report period closes, and those changes may not appear in the report. Your own changes can also shift which provider controls matter to you. Track provider change notices and architecture updates during your observation period, and record each one that could alter the carve-out or inclusive treatment in your system description.
Who owns the subservice decision: your team, your partner and the CPA firm
Your organization owns the subservice decision. Your leadership chooses whether each subservice organization is carved out or included in the system description, and that choice shapes what the auditor tests and what your customers read. Your team also owns the relationship with each provider, including reviewing its SOC report and bridge letters, tracking exceptions, and deciding what to do when a provider's controls fall short.
- Choosing the method: Decide carve-out or inclusive treatment for each provider, and record the reason. Confirm the choice with your CPA firm before fieldwork.
- Owning vendor reviews: Collect each provider's current SOC report, read its exceptions and complementary controls, and file the review under CC9.2.
- Mapping CSOCs to owners: Assign an internal owner to every complementary subservice organization control that your side depends on.
- Signing the assertion: Management signs the assertion and the representation letter, so management must understand how the carved-out providers are described.
- Keeping the list current: Update the provider inventory when you add, replace or drop a dependency during the period.
Before signing, check that every carved-out provider has a current report and that someone on your team can explain each complementary control in plain terms.
An implementation partner such as DeployOpen can prepare the inputs that support your team's decisions. DeployOpen does not issue reports, attestations or certifications. The auditor and your organization own those outcomes, and the partner's role is to organize systems, records and evidence so the decisions are traceable.
- System description inputs: Draft the description of each system component and the provider dependencies that feed the description criteria work.
- Evidence organization: Collect provider reports, contract terms and configuration evidence for shared controls and file them against the relevant criteria.
- CSOC documentation: Write down each complementary subservice organization control, the provider's stated responsibility and the matching internal control.
- CC9.2 records: Prepare vendor risk assessments, review logs and exception follow-up in a form your team and auditor can test.
- Gap identification: Flag where a provider's report does not cover a service you use, so your team can decide how to handle it.
Ask any partner for a written scope that names these deliverables and states who signs each record.
The CPA firm is the independent party. It decides whether your carve-out or inclusive treatment is acceptable for the engagement, tests the controls within scope, including your reliance on provider reports, and issues the opinion. Only the CPA firm can issue the SOC 2 report.
- Accepting the treatment: Confirm early whether the auditor agrees with the chosen method for each provider, since a late change can reshape the system description.
- Testing your reliance: Expect the auditor to test your review of provider reports and the CSOC controls you depend on.
- Obtaining provider evidence: Confirm how the auditor will receive provider reports, including any NDA or access terms.
- Reporting the result: The opinion and the report, with its description of carved-out providers, come from the auditor.
- Setting expectations: Ask the firm in advance what evidence it needs for each provider and how it will document its conclusion.
Check the firm's engagement letter for who provides which deliverables before fieldwork begins.
Subservice organization questions buyers ask
Is the carve-out method always acceptable for a cloud provider in a SOC 2?
Carve-out is acceptable when the service organization's description correctly excludes the subservice organization's controls and the report says so, but it is not automatic. The carve-out method removes the provider's controls from the scope of testing and lists the provider's expected controls as complementary subservice organization controls (CSOCs). The choice depends on whether the service commitments depend on controls the provider runs, how much of the system the provider operates, and whether the provider's own SOC report covers the relevant criteria. Where a provider controls a material part of the security or availability commitments, an examiner may expect the inclusive method or a clearly described carve-out with strong vendor oversight under CC9.2. Confirm the approach with your CPA firm early, because it shapes the system description, the CSOC list and the evidence you must collect.
Can our provider's SOC 2 report replace our own testing of its controls?
A provider's SOC 2 report can serve as evidence for the controls it covers, but it does not replace your own obligations. Under the carve-out method, the report covers only the provider's own system, so you still need to confirm that the report's period, scope and services match what you use. You must read the exceptions, the complementary user entity controls the provider lists, and any qualified opinion. You also need to map the CSOCs to controls you run, such as reviewing the report, tracking exceptions and managing your own configuration and access. Your auditor will ask how you concluded that the report is sufficient. Keep a dated record of that review, the bridge letter if the report period has ended, and the decisions you made about gaps.
How many complementary subservice organization controls should we expect?
The number of CSOCs depends on how many subservice organizations you use, how much of the system each one runs, and how precisely your system description names the controls you rely on. There is no standard count. A simple application hosted on one cloud platform may list a short set of provider controls, while a system that uses several hosting, identity, logging and support providers will list more, each tied to a specific criterion. Ask your examiner or CPA firm how they expect CSOCs to be written, and ask your provider which controls it has documented as its responsibility. Avoid copying a list from another company's report, since the controls must describe your actual arrangements.
What must our team prepare before the auditor reviews subservice organizations?
Preparation has four parts. First, build a register of every subservice organization, the services it provides and the criteria it affects. Second, collect each provider's current SOC report, bridge letter if needed, and its list of complementary controls, and record who reviewed them and when. Third, decide between carve-out and inclusive treatment and document why. Fourth, assign an owner to each CSOC you rely on and keep evidence that the owner performs the check. Also confirm that your management's description and your vendor oversight process use the same names and scope. Gaps in any of these four areas usually appear as exceptions or as questions during fieldwork, so resolve them before the observation period begins where possible.
Can we handle subservice organization reviews in-house?
Yes, many organizations do this in-house, provided they have someone who can read a provider report critically and maintain the register and the evidence. The work is recurring: each provider report changes annually, providers add or retire services, and your own architecture changes. Cost drivers include the number of providers, the complexity of the system, the time your staff spend reading reports and the frequency of changes. Internal teams often underestimate the time needed to reconcile CSOCs with controls and to explain the decisions to an auditor. If you outsource part of the work, decide which decisions remain with your management, because the organization owns its controls and the auditor, not a consultant, issues the report.
How does a DeployOpen engagement differ from the auditor's work on subservice organizations?
DeployOpen is an implementation partner. It can help plan the carve-out or inclusive approach, document the subservice inventory, set up the vendor review workflow, configure the self-hosted platforms that produce evidence, and organize the files that support each CSOC. The engagement scope is agreed in writing before work starts. DeployOpen does not issue SOC 2 reports, opinions or attestations. The CPA firm performs the examination, tests the controls, decides whether the description is fairly presented and issues the report. Your management owns the description, the assertion and the decisions about how each subservice organization is treated. Ask any partner to state in its scope which work it performs and which work remains with you and the auditor.
What to confirm with your CPA firm before you pick a method
Before you choose between the carve-out and inclusive methods, put your questions to the CPA firm in writing and file the answers with the engagement letter. The first question is accepted treatment for each subservice organization: for every cloud provider, colocation facility, managed service or payroll processor in your system, ask whether the firm will accept carve-out, whether it expects inclusive treatment for any of them, and what it needs from you to support either choice. Ask the same question for each report type in scope. A method that works for a Type 2 report may not carry over to a SOC 3 report, and the AICPA staff FAQs address carve-out treatment in SOC 3 reports, so confirm that point directly rather than assuming it transfers.
The second group of questions covers evidence and presentation. Ask which evidence the firm expects for CC9.2, the criterion on managing risks from vendors and business partners, including how it will test your vendor risk assessments, contract terms, exception handling and periodic reviews of each provider's SOC report and bridge letters. Then ask how the method will appear in the system description, meaning which subservice organizations are named, how the complementary subservice organization controls are described, and whether the firm wants the provider's controls listed in your own control matrix. Confirm who signs the description and the assertion so that the words describing each provider match what your team can evidence.
Finally, tie these answers to the engagement letter. Ask the firm to state the chosen method, the subservice organizations it covers, and the evidence you must provide in its scope section, along with any change in treatment that would require a new discussion. If the firm's answer changes after you have already built your controls, the cost of rework lands on your team, so resolve it before fieldwork begins. Your implementation partner can prepare the evidence, but only the CPA firm decides whether the method is acceptable and issues the report.
How DeployOpen prepares subservice evidence for your audit
DeployOpen prepares the systems, documents and evidence your organization needs to present its subservice organizations correctly under the carve-out or inclusive method. Your organization decides the method and owns its controls, and only the independent CPA firm issues the report.
How we scope
- Each engagement starts with a written scope that names every subservice organization and the criteria each one touches
- We confirm with you which method, carve-out or inclusive, applies to each provider before any work begins
- Scope also records which provider reports you will rely on, such as their SOC 2 report, and which controls they cover
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts
How we build
- We map the controls you run in your own environment against the subservice controls you expect each provider to perform
- We draft the complementary subservice organization controls list and align it with the system description
- We set up vendor oversight records for CC9.2, covering risk assessment, responsibilities and periodic review of provider reports
- We configure logging and access records in your infrastructure so provider-related evidence can be produced on request
How we hand over
- You receive a documented subservice inventory, control mapping and oversight procedure written for your own environment
- Evidence packages are organized by control, with dated system-generated records where your tooling produces them
- Gaps and open questions are listed in writing so your team and CPA firm can resolve them before fieldwork
- Your organization reviews and signs off the documents, since management owns the description and assertion
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial engagement
- Retainers can cover periodic review of provider reports and updates to the subservice inventory as providers change
- Before your audit, confirm with your CPA firm which evidence format they accept and how they plan to handle provider reports
- Ask any provider you rely on for its current SOC report and the process for obtaining it under its NDA terms
