SOC 2 vendor management and subservice organisations: carve-out, inclusive, CSOCs and the review record

Vendors and subservice organisations are not the same thing

A vendor is any third party that supplies you. A subservice organisation is a narrower group: a vendor that performs part of the service you deliver to clients, and whose controls are needed, together with yours, for your system to meet the criteria in scope. The distinction decides how the provider appears in your report.

A practical test is to ask, for each vendor, whether a failure of its controls could breach a commitment you have made to clients about the system being examined. Your infrastructure host almost always passes. The firm that supplies office furniture does not.

Other vendors still matter: the risk assessment (CC3) and risk mitigation (CC9) criteria expect vendor risk to be identified and managed, so every vendor belongs in your inventory and tiering. Only subservice organisations are named in the system description and treated by one of the two methods below. Where the boundary of the system itself is still undecided, the SOC 2 scope guide covers that choice.

The carve-out and inclusive methods, and how each shows in the report

Under the carve-out method, the subservice organisation's controls stay outside the examination. Your system description names the provider and the services it performs, identifies the controls you expect it to operate, and describes how you monitor it. The service auditor does not test the provider's controls; the opinion states that they were excluded.

Under the inclusive method, the provider's relevant controls come inside your examination. They are described in your system description, the service auditor tests them, and the results appear in your report. It needs the provider's written assertion and access for the service auditor, which is why large cloud providers almost never agree to it.

Different providers in one report may be treated by different methods, but no subservice organisation may be left out of the description.

CSOCs and CUECs: the controls someone else has to run

Complementary subservice organisation controls

When you carve a provider out, your system description lists the controls you assume that provider operates, because your own controls only achieve the criteria if those assumed controls work. These are complementary subservice organisation controls, or CSOCs. Map each CSOC to the criterion it supports and confirm that the provider's own report examined a matching control.

Complementary user entity controls

Complementary user entity controls, or CUECs, run the other way: they are the controls your clients must operate for your controls to achieve the criteria. Managing their own users' access to your platform is the classic example.

When you read your cloud provider's report, you are the user entity. The CUECs in that report are controls you must run, and your service auditor will expect to find them among your own. The guide to reading a SOC 2 report explains how clients should read the CUECs you publish in yours.

Tiering vendors, due diligence and the annual review

Tiering by risk keeps the effort where the exposure is. Base the tier on the data the vendor touches, the part of the service it supports and how hard it would be to replace. The tiers and review frequency are set in your own policy; the table shows one common pattern.

Reviewing a vendor's SOC report

Check that the report covers the services and region you use, that its period is recent, what the opinion says, whether any exceptions touch controls you rely on, which CUECs apply to you, and whether it carves out providers of its own.

Where the vendor's report period ended some months before your own period does, ask for its bridge letter, in which the vendor's management states whether anything material has changed since its report. It is a management statement, not an opinion. The guide to bridge letters and the annual cycle covers how they work from your own side.

A worked example: a SaaS company on a major cloud platform

Consider a software company whose scheduling platform serves enterprise clients. It hosts everything on one of the large cloud providers, takes subscription payments through a card payments processor and uses a dozen other tools for e-mail, code hosting and ticketing.

The cloud provider is a subservice organisation and is carved out. The description names it, lists the CSOCs assumed, such as physical security, and describes the annual review of the provider's report. The provider's CUECs become the company's own account and encryption controls.

The payments processor needs more thought. It handles the company's own billing of its clients, not the scheduling service the clients rely on, so for this system it is a critical vendor rather than a subservice organisation. Had the platform processed payments for its clients, the processor would have been a subservice organisation.

Code hosting supports change management and goes in the critical tier; the other tools are tiered high or standard.

The record the examiner asks for

In a Type 2 examination the service auditor tests whether your vendor controls operated during the period, so evidence must carry dates. Expect requests for:

• the approved vendor management policy, with tiering rules and review frequency;
• the vendor inventory, with the tier, the data each vendor touches and whether it is a subservice organisation;
• for vendors onboarded during the period, the due diligence completed before access was granted;
• contracts or terms for critical vendors showing security, confidentiality and breach notification obligations;
• the review of each subservice organisation's report within the period, with exceptions considered and CSOCs checked;
• evidence that the CUECs from providers' reports are operated as your own controls.

A spreadsheet updated the week before fieldwork rarely survives this.

Where vendor management goes wrong

• Filing the provider's report without reading it. A download date is not a review.
• Listing CSOCs that the provider's report does not cover. Every assumed control should trace to something the provider's service auditor examined.
• Ignoring the provider's CUECs. Misconfigured cloud accounts are a common source of exceptions.
• Missing vendors. Tools adopted without procurement often hold client data and never reach the inventory.
• A description out of step with reality. A provider changed mid-period without updating the description creates a mismatch.

The SOC 2 common mistakes guide covers the full set.

SOC 2 vendor management: questions buyers ask