The inclusive method includes a subservice organisation’s controls within the service organisation’s system description and audit opinion. This gives customers a fuller view of the control environment, but it also increases the evidence burden on the organisation being audited. It is useful when the subservice controls are integral to the service being delivered.
What the inclusive method changes in a SOC 2 report
The inclusive method brings the subservice organisation into the service organisation’s own scope narrative rather than separating it out. Practically, that means the auditor describes the service more completely, because the controls supporting delivery are presented as part of the system under examination. It is most useful when the outsourced or supporting controls are tightly coupled to how the service actually works.
That tighter scoping matters because customers and auditors can see the control environment as one combined operating model instead of two loosely connected ones. In SOC 2 Guide, this is the same idea that drives how carve-outs, complementary user entity controls, and subservice organisation controls are explained to readers who need the full assurance picture.
When the method is used well, it reduces ambiguity about where critical controls live and how they support the service commitment. That makes it easier to understand dependencies, especially where the subservice organisation provides functions that are operationally inseparable from the audited service.
Why the inclusive method is chosen over a carve-out
The inclusive method is usually chosen when the subservice organisation’s controls are not just adjacent to the service, but integral to it. In that case, excluding those controls can understate the real control environment and leave readers with an incomplete view of how the service is secured and delivered.
This approach is also helpful when the service organisation wants the audit opinion to reflect a broader operational reality. If a supporting provider is effectively part of the service chain, then the inclusive method makes the audit narrative align more closely with how customers experience the service and how risk is actually managed. The broader SOC 2 structure, including bridge letters and evidence expectations, is also discussed in the SOC 2 Guide.
The trade-off is straightforward: better transparency, but more work. The organisation being audited must gather and present evidence for a wider set of controls, and the audit team must be satisfied that the subservice controls are operating effectively enough to be described within the opinion scope.
What the method means for evidence, scope, and customer confidence
Evidence burden is the main operational consequence. Once a subservice organisation is included in the system description and audit opinion, the service organisation has to support that inclusion with enough documentation, operating evidence, and control narrative to show how the combined environment works in practice.
That wider scope can improve customer confidence, but only if the organisation can explain the relationship between the service organisation and the subservice organisation clearly. If the boundaries are muddy, the method can create more confusion than assurance, because readers may not know which controls are owned, inherited, or operationally shared.
For that reason, the inclusive method works best when the support provider’s controls are stable, well-understood, and easy to evidence. If the relationship is fluid, or if the supporting service changes often, the organisation may struggle to keep the audit story consistent across the observation period.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
SOC 2 (AICPA) provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SOC 2 (AICPA) | CC6.1 — Logical Access Security Measures | Inclusive-method reporting depends on how access controls are scoped across the combined service environment. |
| CC2.3 — Communicate Internal Control Information | The method changes how the service organisation communicates its control environment to customers and auditors. | |
| CC3.2 — Assess and Manage Risks from Third Parties | Including a subservice organisation reflects third-party control dependence and its assurance impact. | |
| Recommendation — Document inherited and shared access controls clearly across the combined service scope. Describe the subservice relationship and control boundaries in the system description. Evaluate third-party control dependence before deciding whether to include it in scope. | ||
Practitioner Guidance
What to verify: Confirm that the subservice organisation’s controls are truly integral to service delivery before choosing the inclusive method. If the dependency is only incidental, the extra scope can create avoidable audit complexity without improving assurance.
What to measure: Track whether the combined control narrative can be supported with complete, current evidence across the full audit period. Gaps in inherited control testing, ownership clarity, or subservice reporting are the first sign that the method may be too heavy for the operating model.
Decision rule: Use the inclusive method when the customer would reasonably expect the subservice controls to be part of the service’s assurance story, and when the organisation can produce evidence without relying on ad hoc explanations or exceptions.
Practitioner takeaway: The inclusive method is not just a scoping choice, it is an evidence and transparency commitment, so only use it when the subservice dependency is real enough to justify the wider audit burden.