A fixed-price gap analysis, remediation through to your audit, and upkeep after it. All in a workspace you keep.
All compliance →Led by a published security researcher with five CVEs. One standard report, letters for your buyers, and retests of your fixes.
All security →To the people you sell to, raise from or answer to.
All industries →Original research, free tools, and plain-language guides on security and compliance, from a published security researcher.
Read the blog →Almost every SOC 2 report carves out its cloud provider. Doing that correctly creates a monitoring obligation your auditor will test, and a set of controls the report assumes someone else is running.
A subservice organization is a vendor whose controls are necessary, together with your own, for the trust services criteria to be achieved. Your SOC 2 report handles them one of two ways. Under the carve-out method you name the subservice organization and the services it provides, exclude its controls from the scope of the examination, and list the complementary subservice organization controls you assume it operates. Under the inclusive method its relevant controls are brought inside your report, tested by your auditor, and covered by an assertion the subservice organization itself signs. In practice almost everyone carves out, because the large cloud providers will not participate in anyone else's examination. Carving out is not a way of avoiding the risk: it obliges you to monitor the provider, and your monitoring controls are inside the scope of your report and get tested.
The numbers
The figures that shape the short answer above. Where they come from is cited in the sections that follow.
Free PDFs, no card
The SOC 2 readiness checklist, the ISO 27001 gap checklist and the vendor security questionnaire, as PDFs you can print or hand to your team. Free, no card.
From Jacob Masse, principal of traztech: the files by email, then a few short notes over the next month. No spam, unsubscribe in one click.
A subservice organization is a vendor used by a service organization whose controls are necessary, in combination with the service organization's own controls, for the applicable trust services criteria to be achieved. The test is not how important the vendor is commercially, or how much you spend with them. It is whether the criteria in your report can be met without relying on controls that vendor operates.
This distinction matters because it is narrower than most people's definition of a critical vendor. Your cloud hosting provider is almost always a subservice organization: the physical security, environmental controls and much of the infrastructure layer supporting your service are theirs, and no control you operate can substitute for them. A managed database or platform provider that runs the layer your data sits on is usually one too. A payment processor handling cardholder data on your behalf frequently is.
A vendor whose failure would be commercially painful but whose controls do not sit inside your service delivery is generally not a subservice organization. Your payroll provider holds employee data and is a real third-party risk, but the trust services criteria describing your product are not achieved through their controls. Your email provider, your CRM, your ticketing system, and your compliance automation tool are usually in the same category. They belong in your vendor risk program; they do not belong in the subservice organization section of your report.
Getting the boundary right is worth a real conversation with your auditor early in scoping, because it drives what the description has to say, what has to be monitored, and where the reader's attention will go. Listing too many organizations makes the report noisy. Omitting a genuine one is a description problem the auditor should catch and, if they do not, a problem a sophisticated customer will.
Under the carve-out method, your system description identifies each subservice organization, describes the nature of the services it provides, and explicitly excludes its controls from the description and from the scope of the examination. Your auditor performs no procedures on those controls and expresses no opinion on them. In their place, the description sets out the controls you assume the subservice organization is operating: the complementary subservice organization controls.
The reader is therefore told three things: that a portion of the system is delivered by someone else, who that someone is and what they do, and which of their controls the rest of the design depends on. What they are not told is whether those controls worked, because nobody tested them here.
What stays inside your scope is your own management of the relationship. You are still expected to have controls that address selecting the subservice organization, agreeing security obligations with them, and monitoring the effectiveness of their controls on an ongoing basis. Those monitoring controls are yours, they sit inside the examination, and they get tested like any other control.
This is the point most often misunderstood. Carve-out is not a way of pushing risk off the report. It converts a set of operational controls into a monitoring obligation, and the monitoring obligation is what your auditor examines. A company that carved out its cloud provider and cannot show it reviewed that provider's assurance report has a testable control failure in its own report.
Under the inclusive method, the subservice organization's relevant controls are described inside your system description and are inside the scope of the examination. Your service auditor tests them alongside your own. The subservice organization provides its own written assertion covering its portion, and its management is a participant in the engagement rather than a subject of it.
The result is a single report with no gap at that boundary: the reader sees tested controls end to end across both organizations, and there are no complementary subservice organization controls to reason about for the included services, because nothing about them is being assumed.
The practical requirements are steep. The subservice organization has to agree to participate, sign an assertion, give your auditor access to its people, systems and evidence, and accept being named in a report it does not control. It has to be willing to do this on your timetable and for your period. Legal on both sides has to work out liability and confidentiality.
That is why the inclusive method is uncommon. It is realistic where the subservice organization is small relative to you, where there is a close commercial relationship, or where it is a group company. A wholly-owned subsidiary running part of the platform is the textbook case. An affiliated data processor with the same parent is another. A hyperscale cloud provider is not: they issue their own reports at scale and have no reason to be a participant in yours, and asking is not a productive use of the relationship.
One consequence worth planning for: an inclusive report is materially more work to produce. Scoping, evidence collection and remediation now span two organizations with different calendars and different priorities, and any delay on their side is a delay to your report. Where an inclusive treatment is genuinely wanted, start the conversation with the subservice organization before you commit to an audit window rather than after.
For most organizations the choice makes itself. If the subservice organization will not participate, you carve out. That single fact settles cloud hosting for essentially every SaaS company.
Where there is a real choice, the question to ask is what the reader needs. If the subservice organization issues its own credible, current assurance report covering the relevant criteria, carve-out costs the reader almost nothing, because they can obtain that report and read it alongside yours. If it does not issue one, carving it out leaves a hole in the assurance that nothing fills, and an inclusive treatment or a hard conversation about replacing the vendor is the honest answer.
Consider also how much of your service the subservice organization delivers. Carving out infrastructure that supports a system whose application-layer controls are all yours is normal and well understood. Carving out something that constitutes most of what your customer actually buys produces a report that appears to cover a service while excluding the substance of it. Sophisticated buyers notice, and it damages the report's usefulness in the deals it was bought to unblock.
The methods are chosen per subservice organization, not once for the whole report. A report that carves out its hyperscale cloud provider and includes a small affiliated processor is perfectly coherent, and the description simply says which method applies to which.
Decide during scoping, before the observation window opens, and record why. Changing method mid-period is disruptive and can invalidate evidence collected under the earlier assumption.
The trust services criteria expect a service organization to assess and manage risks associated with vendors and business partners, and the description criteria expect a carve-out to be paired with monitoring of the subservice organization's controls. What that means operationally is a small, repeatable program, and the strength of it is what an auditor tests.
First, maintain an inventory that identifies subservice organizations distinctly from ordinary vendors. Being able to answer "which of your vendors are subservice organizations and why" in a sentence is the base of everything else.
Second, obtain each subservice organization's current assurance report, normally a SOC 2 Type II, and read it. Reading it is the part that gets skipped and the part auditors ask about. A read produces a short written note covering the period covered, whether the period leaves a gap against your own, the opinion and any qualification, every exception in the testing section and whether it touches a service you rely on, and their complementary user entity controls, which are controls you are supposed to be operating. Two pages of notes per critical provider, once a year, is the whole exercise.
Third, deal with the period gap. Provider report periods rarely align with yours, and a carve-out with a six-month uncovered gap is a real weakness. The usual mitigations are obtaining a bridge letter from the provider, or documenting what other monitoring covered the gap. Our guide to SOC 2 bridge letters explains what such a letter can and cannot assert.
Fourth, monitor operationally rather than only annually. Subscribe to the provider's status and security bulletins, route them to a monitored destination with a named owner, and record the response to anything material. An annual document review plus a live channel is a defensible program; either one on its own is thin.
Fifth, have the contract carry the security obligations you are relying on, and confirm at renewal that it still does. Where a provider issues no assurance report at all, the compensating position is a documented risk acceptance naming who accepted it, plus whatever direct evidence you can obtain, such as a completed questionnaire or a right-to-audit clause you have actually exercised.
Sixth, put all of it on a calendar with owners. Annual report collection and review, contract review at renewal, and a periodic reconciliation of the vendor inventory against expense and single sign-on data to catch dependencies that appeared without going through procurement.
Complementary subservice organization controls, or CSOCs, are the controls you assume the carved-out organization operates and which are necessary for the criteria to be achieved. They are the upward-facing mirror of complementary user entity controls, which face downward towards your customers. Neither set is tested by your auditor.
For a cloud hosting provider the standard set is recognisable: physical access controls at data centres, environmental protection and power, controls over the hypervisor and the physical network separating tenants, media sanitisation on decommissioning, and controls over the provider's own personnel with access to the underlying infrastructure. Where you use managed data services, add backup and replication mechanisms at the layer they operate.
Write them from the actual division of responsibility rather than from a template. The major cloud providers publish shared responsibility documentation that maps cleanly onto this, and using it means your CSOC list reflects the services you actually consume. A company running entirely on managed container and database services has a materially different CSOC list from one running virtual machines it patches itself, and a copied list will describe the wrong company.
Keep the list current. Adopting a managed service in place of something you previously ran yourself moves controls from your side of the line to theirs, and the report should reflect that in the period it happened. This is one of the clearest cases where a system description drifts out of date without anyone noticing, because the engineering change that caused it never touched a compliance document.
For a reader, the CSOC list is the instruction for what to read next: it tells you exactly which controls to look for in the provider's own report. That is the intended use, and a reader who follows it is doing the assessment properly.
Subservice organizations surface in several places, and reading them together is how you understand the real boundary.
The service auditor's report, which carries the opinion, generally states which subservice organizations were carved out and confirms that their controls were not included in the scope of the examination. This language is short, easy to skim past, and is the definitive statement of what the opinion covers. Where the inclusive method was used, the report instead identifies which of their controls were within scope.
Management's assertion aligns with the same boundary. Under the inclusive method there is an additional assertion from the subservice organization's own management covering their portion.
The system description names each subservice organization, describes the services provided, states the method used, and sets out the CSOCs. It should also describe how you monitor them, since that is a control of yours.
The controls and testing section is where your monitoring controls appear with their tests and results. Under the inclusive method, the subservice organization's controls appear here too, with their own tests and results, which is the visible difference between the two methods on the page.
A note on reading unfamiliar reports: check whether the subservice organizations named in the description match the ones named in the opinion. Mismatches happen, usually because a vendor changed late in the period and only one section was updated, and it is a fair question to put to the vendor.
Under carve-out, your auditor tests your controls over the relationship, and there are four or five of them in a typical engagement.
They test that the vendor inventory is complete and identifies subservice organizations, usually by comparing it against your infrastructure and, in a thorough engagement, against expense data. A production dependency absent from the inventory is an exception.
They test that assurance reports were obtained for the period. For a Type II they will want to see this happening within the observation window rather than assembled at the end, because the control being tested is periodic monitoring and a single burst of activity in the final fortnight does not evidence a recurring control.
They test that the reports were reviewed rather than just filed. This is where the written review note earns its keep. A folder of PDFs with no notes evidences collection, not review, and experienced auditors ask the person named as the reviewer what the exceptions in the provider's report were.
They test that exceptions and period gaps were considered and that something was decided. A note saying the provider reported an exception in an area you do not use, with a sentence explaining why, is a complete answer. Silence is not.
They test that contracts carry the security terms you claim to rely on, typically by sampling agreements for the critical providers.
Under the inclusive method, in addition to all of the above, they perform ordinary tests of the subservice organization's in-scope controls: sampling their evidence, interviewing their people, and reporting exceptions in your report. That is the substantive workload difference between the two methods.
If you are reading someone else's report, this section tells you how much of the service you are actually getting assurance over, and it takes ten minutes to work through.
Identify each subservice organization and the services it provides. Confirm which method was used for each. For anything carved out, ask whether the carved-out portion is peripheral or central to what you are buying.
Read the CSOC list as a to-do list of its own. It tells you which controls to look for in the provider's report. For a hyperscale cloud provider you can obtain that report yourself, so the chain is walkable end to end. For a smaller provider you may have to ask the vendor whether they hold it, which is itself a useful question.
Ask the vendor how they monitor their subservice organizations, and specifically whether they read the provider's reports and what the last review found. A vendor who can answer that in detail is running a real program. A vendor who has to go and check has told you something too.
Check the period alignment between the vendor's report and their providers' reports, and ask about anything uncovered.
Finally, note that the vendor's report also carries a list of controls it assumes you are operating. Those are the complementary user entity controls, and they are covered in the CUEC guide. Between the two lists you can see the entire chain: what their providers are assumed to do, what the vendor was tested on, and what you are assumed to do.
| Dimension | Carve-out method | Inclusive method |
|---|---|---|
| Scope of the examination | The subservice organization's controls are excluded. Your auditor performs no procedures on them. | Their relevant controls are inside the scope and are tested by your auditor. |
| What the description says | Names the organization, describes the services, states the exclusion, lists the complementary subservice organization controls assumed. | Describes their in-scope controls as part of the system, with no CSOCs needed for the included services. |
| Assertions required | Your management asserts on your system only. | Your management plus the subservice organization's management, each asserting on their portion. |
| Their cooperation needed | None beyond ordinary contractual terms and providing their own assurance report. | Substantial: participation in the engagement, auditor access to people and evidence, and a signed assertion. |
| Feasible with a hyperscale cloud provider | Yes. This is the normal treatment and what the provider expects. | No in practice. They issue their own reports and will not participate in yours. |
| Your obligation that remains | Selection, contracting, and ongoing monitoring of their controls. Those monitoring controls are tested in your report. | The same relationship management, plus coordination of a two-organization audit. |
| Effect on cost and timeline | Lower. The examination stays within your own boundary. | Higher. Fieldwork spans two organizations and their calendar becomes your critical path. |
| What the reader gets | A gap at the boundary that they close by reading the provider's own report alongside yours. | Tested coverage across both organizations in one document. |
| Failure mode | Reports collected but never read, and period gaps nobody covered with a bridge letter. | The subservice organization's remediation slips and your report date moves with it. |
| When it is the right choice | Almost always, and particularly where the provider issues its own credible current assurance report. | Group companies, affiliated processors, and providers who issue no report but deliver a central part of the service. |
A vendor whose controls are necessary, in combination with your own, for the applicable trust services criteria to be achieved. Cloud hosting providers and managed platform providers are the usual examples. A vendor that is commercially critical but whose controls do not form part of your service delivery, such as a payroll or CRM provider, is normally an ordinary third-party risk rather than a subservice organization.
Under carve-out, the subservice organization's controls are excluded from the scope of your examination and the report instead lists the controls you assume they operate. Under the inclusive method, their relevant controls are inside the scope, tested by your auditor, and covered by an assertion their own management signs. Carve-out is by far the more common because it needs no participation from the provider.
No, in practical terms. The inclusive method requires the subservice organization to participate in your engagement, give your auditor access to its evidence and sign an assertion in your report. Hyperscale providers issue their own assurance reports at scale and do not participate in customers' examinations. Carve them out and monitor them using the report they publish.
No. Carve-out is a scoping decision about whose controls get tested, not a transfer of risk. You remain responsible for selecting the provider, agreeing security obligations with them, and monitoring the effectiveness of their controls. Those monitoring controls are inside your report and your auditor tests them, so a carve-out with no evidence of monitoring is a control failure in your own examination.
CSOCs are the controls you assume a carved-out subservice organization is operating and which are necessary for the criteria to be achieved: for a cloud provider, typically data centre physical security, environmental controls, hypervisor and network separation, media sanitisation, and controls over their own privileged personnel. Your auditor does not test them. They tell a reader which controls to look for in the provider's own report.
Obtain their current assurance report each year and write a short review note: the period covered and whether it leaves a gap against yours, the opinion and any qualification, each exception and whether it touches a service you use, and their complementary user entity controls, which are controls you are supposed to be running. Add a live channel for status and security bulletins with a named owner, and keep the contract terms under review at renewal.
That gap is a real weakness and auditors ask about it. The usual answers are to obtain a bridge letter from the provider covering the interval between their report end date and yours, or to document what other monitoring covered the period. A bridge letter is unaudited and cannot carry the same weight as a report, so treat it as a partial answer rather than a complete one.
No. Over-listing clutters the description and creates monitoring obligations you will then fail to meet. Apply the test in the definition: could the criteria in your report be achieved without relying on controls that vendor operates? If yes, they belong in your vendor risk program rather than in the subservice organization section.
traztech Workspace has all 61 criteria of SOC 2 written in plain English, with what the standard asks for, what to do about it, and somewhere to attach the proof. You answer them, it scores you, and nothing is locked behind an upgrade.
No credit card, no trial clock, no locked features. We make money when someone wants help closing the gaps, not from the Workspace.
| traztech Workspace | Other GRC platforms | |
|---|---|---|
| Licence cost | $0. Free forever, no card, no paid tier | $7,500 to $50,000 a year, on an annual contract |
| Control library, evidence register, policy templates, risk register, vendor questionnaires, readiness scoring | Included | Included |
| What it costs inside an engagement with us | $0. You need a workspace either way | Unchanged. The subscription sits on top of the fee |
| What it does to your audit quote | A documented readiness position the audit firm can scope and price against | Nothing. The audit firm prices your readiness, not your tooling |
Platform pricing is a publicly reported range, since none of them publish a number. The fuller comparison, including when a paid platform is the better buy, is on the Workspace page.
We scope subservice organizations with your auditor, write the description and the CSOC list from your real architecture, and build the monitoring program that has to sit behind a carve-out.
Book a strategy callEveryone on our list also gets The Compliance Brief, one email every Tuesday on what changed in security and compliance that week. Read the latest issue.