SOC 2 Subservice Organisations: Carve-Out Explained
A subservice organisation is a provider whose controls your SOC 2 report depends on, such as AWS, Azure or Google Cloud. You have two ways to handle it. The carve-out method names the provider, excludes its controls from testing, and lists the controls you assume it performs. The inclusive method tests the provider’s controls inside your report, which requires its cooperation. Almost every Australian SaaS company uses carve-out.
That choice sounds administrative. It is not. It changes what your report says, what your customers have to do with it, and how much your auditor charges. Here is how each method works and which one will apply to you.
What is a subservice organisation in SOC 2?
A subservice organisation is a third party whose services form part of your information system and whose controls are necessary for you to meet the trust services criteria you are reporting on. Cloud infrastructure providers, data centres, payment processors and managed service providers that patch or monitor your production systems are the usual examples.
Not every vendor is a subservice organisation. The test is whether you rely on that provider’s controls to achieve a criterion in your report. Your accounting software, your office supplier and your law firm are vendors, not subservice organisations, because none of them performs a control you are claiming credit for.
Getting this classification right matters because it changes your report’s scope and its required disclosures. Over-identifying vendors as subservice organisations clutters the report with controls you do not actually depend on. Under-identifying them is worse, because your auditor will find the gap and your description will be wrong. Our guide to SOC 2 scope covers the wider boundary decision this sits inside.
What is the SOC 2 carve-out method?
The SOC 2 carve-out method excludes a subservice organisation’s controls from the scope of your examination. Your system description still names the provider, describes the nature of the services it performs, and states the types of controls that have been excluded. Your auditor’s opinion then covers only your own controls.
Carve-out is the standard approach and is permitted under AT-C Section 320, the attestation standard governing reports on controls at service organisations. It is standard for a practical reason: AWS, Microsoft and Google will not participate in your audit. They run their own SOC programmes serving thousands of customers and have no mechanism to be tested inside yours.
The trade-off is that carve-out shifts work to your customer. Because your report does not cover your cloud provider’s controls, a customer who needs assurance over those controls has to obtain the provider’s own SOC 2 report separately. In practice this is a non-issue for hyperscalers, because their reports are readily available through their compliance portals.
What are complementary subservice organisation controls?
Complementary subservice organisation controls, usually abbreviated to CSOCs, are the controls you assume your subservice organisation performs in order for your own controls to achieve the trust services criteria. When you use the carve-out method you must list them, because they are the controls nobody tested but everybody is relying on.
A typical CSOC list for an Australian SaaS company running on a hyperscaler includes:
- Physical access controls at the data centres hosting your environment
- Environmental protections such as power, cooling and fire suppression
- Controls over the hypervisor and the underlying host infrastructure
- Secure media disposal and decommissioning of storage hardware
- Network infrastructure controls at the provider’s layer
CSOCs are frequently confused with complementary user entity controls, or CUECs. The distinction is direction. CSOCs are controls your provider performs beneath you. CUECs are controls your customer performs above you, such as configuring their own user access correctly or enabling the multi-factor authentication your product offers. Both appear in the report and both are often skimmed, which is why our guide to reviewing a supplier’s SOC 2 report treats them as the first thing to read, not the last.
What is the inclusive method and when would you use it?
The inclusive method brings the subservice organisation inside the scope of your SOC 2 examination. Your system description covers both environments, your auditor tests controls at both organisations, and the resulting opinion covers both. The subservice organisation’s management must also provide a written representation to your auditor.
The inclusive method produces a more complete report, and it removes the homework your customers would otherwise have. It is rarely used because it requires the subservice organisation to agree to participate, grant your auditor access to its people and systems, and accept responsibility for part of a combined description. Large providers will not do this.
Where the inclusive method does appear is between closely held entities. If a related company in your group runs your infrastructure, or you use a small specialist provider that wants to support your certification, the cooperation problem disappears and inclusive becomes workable. Expect a longer and more expensive examination either way.
How should an Australian SaaS company handle subservice organisations?
An Australian SaaS company should expect to use the carve-out method for its cloud provider and for any vendor that touches customer data on its behalf. The practical work is identifying every such provider, writing an accurate description of what each one does, and listing the CSOCs you depend on.
| Step | What to do | Common mistake |
|---|---|---|
| 1. Inventory | List every provider touching production or customer data | Missing a monitoring or backup vendor |
| 2. Classify | Decide which are subservice organisations and which are plain vendors | Naming every SaaS tool you pay for |
| 3. Describe | Write what each provider does, in your system description | Vague wording that your auditor rejects |
| 4. List CSOCs | State the controls you assume the provider performs | Copying a generic list that does not match your setup |
| 5. Collect assurance | Obtain each provider’s own SOC 2 or ISO 27001 report | Never actually reading the reports you collect |
| 6. Review annually | Re-check the list before each examination period | A new vendor added mid-year and never classified |
Step five is where most of the real risk sits. Collecting a provider’s SOC 2 report and filing it unread is a control that exists on paper only. If the provider’s report carries a qualified opinion or a long list of exceptions, you need to know, because your reliance on them is now weaker than your description claims. Our article on what a qualified SOC 2 opinion means explains what to look for.
The shared responsibility boundary between you and your cloud provider is the same boundary that defines your CSOCs, which is why it is worth getting clear once. We cover it in detail in our guide to the SaaS shared responsibility model.
Common questions
What is a subservice organisation?
A subservice organisation is a third party whose services form part of your information system and whose controls you rely on to meet the trust services criteria in your SOC 2 report. Cloud hosts, data centres, payment processors and managed service providers performing patching or monitoring are typical examples. Vendors whose controls you do not rely on are not subservice organisations.
What is the SOC 2 carve-out method?
The carve-out method excludes a subservice organisation’s controls from your SOC 2 examination. Your system description names the provider and the nature of its services, states which types of controls are excluded, and lists the complementary subservice organisation controls you assume it performs. Your auditor’s opinion then covers only your own controls. It is the standard approach for cloud-hosted companies.
What is the difference between a SOC 1 and a SOC 2 report?
A SOC 1 report addresses controls relevant to a user entity’s internal control over financial reporting, and is used when your service could affect a customer’s financial statements. A SOC 2 report addresses the trust services criteria covering security, availability, processing integrity, confidentiality and privacy. Subservice organisations and the carve-out method apply to both report types.
Is SOC 2 mandatory?
SOC 2 is not mandated by Australian law. It is a commercial requirement that arrives through procurement, most often when you sell to larger enterprises or to North American customers. Many Australian businesses pursue it because deals stall without it. Where a legal obligation does apply, it usually comes from the Privacy Act rather than from any SOC framework.
What is the equivalent of SOC 2 in Australia?
Australia has no direct equivalent of SOC 2, which is administered by the American Institute of Certified Public Accountants. The closest comparable assurance for Australian buyers is ISO 27001 certification, which is internationally recognised and widely accepted in local procurement. Many Australian SaaS companies hold ISO 27001 for local customers and add SOC 2 when selling into the United States.
Getting the scope right before your audit
Subservice organisations are one of the easiest parts of a SOC 2 examination to get wrong and one of the cheapest to fix early, because it is a documentation and classification exercise rather than an engineering one. You can read the AICPA’s overview of the SOC suite of services for the formal framing. If you want help defining your boundary and preparing the description before the auditor arrives, our SOC 2 services cover readiness through to examination. Get in touch to talk it through.