Should organisations treat subservice organisations as part of SOC 2 scope?

How Subservice Organisations Fit Into SOC 2 Scope

Subservice organisations are not automatically “in scope” in the same way as your own operations, but they are part of the assurance story when they support the system under audit. The practical test is whether they can affect the services, controls, data handling, or availability commitments that appear in the SOC 2 report. If they can, they belong in the system description and risk narrative.

That is why auditors and customers care less about the vendor label and more about the control relationship. A subservice organisation can be relevant because it processes customer data, runs infrastructure, supports authentication, or otherwise influences the trust criteria you claim to meet. The question is not whether the third party is “yours”, but whether its role changes the control environment the report is describing.

For vendor scope decisions, the most useful starting point is the SOC 2 Trust Services Criteria (AICPA), because the report has to describe the system and the controls that support it. That description should make clear what the subservice organisation does, whether it is complementary or inclusive in the service model, and whether its own assurance evidence helps substantiate the reporting organisation’s control environment.

What “In Scope” Usually Means for Subservice Organisations

In SOC 2, “scope” should be read as evidence and boundary scope, not just legal ownership. If a subservice organisation hosts production infrastructure, stores regulated or customer data, provides a critical platform dependency, or performs a control-relevant function such as logging, monitoring, backup, or IAM support, its activities may need to be described because they affect the trust services criteria.

That is especially important when the organisation relies on shared responsibility. A cloud provider, managed service provider, payment processor, or support platform may not be audited as if it were your internal team, but the control design still depends on what it does and what assurance you can obtain from it. This is where the relationship matters: you may not control the subservice organisation, but you still need to account for the risk it introduces.

When a vendor’s own report is used to support your SOC 2 position, the key point is not to overstate what it proves. Third-party assurance can strengthen the narrative, but it does not replace your own control design, monitoring, and oversight. For practical scoping, pair that thinking with a third-party risk view such as DORA where operational dependence and outsourced ICT services materially affect resilience and accountability.

How to Decide Whether a Subservice Organisation Belongs in the System Description

The decision usually turns on whether the vendor’s role is materially connected to the service commitments you are making. If the subservice organisation can affect confidentiality, availability, processing integrity, or privacy, it should be described in a way that makes the dependency understandable to the reader of the report. If it is only a peripheral supplier with no meaningful control impact, it may belong in the background materials rather than the system description itself.

Two details matter most. First, explain what the subservice organisation actually does, not just its name. Second, state whether its assurance report, SOC 2 bridge, contractual commitments, or control attestations are part of the evidence story. That helps avoid a common mistake, which is listing vendors without showing why they matter to the control environment.

For broader vendor and supply-chain context, the ENISA Threat Landscape is useful because it reinforces the real-world exposure created when service delivery depends on third parties and shared infrastructure. That perspective is especially relevant when the subservice organisation is part of the operational path for sensitive data or uptime commitments.

Practitioner Guidance

What to verify: Verify that each subservice organisation is tied to a specific service dependency, control, or data flow, not just named as a supplier. If you cannot explain the control impact in one sentence, the scope statement is probably too vague.

What good looks like: The system description should say what the vendor does, whether it is a complementary or inclusive component of the service, and what assurance evidence supports that dependency. A strong report lets a customer understand the boundary without guessing where responsibility shifts.

Common mistake: Treating every outsourced provider as equally important, or assuming a vendor’s SOC report automatically covers your own control obligations. The better test is whether the vendor’s role changes the risk profile of the service you are attesting to.

Practitioner takeaway: Scope subservice organisations by control relevance, not by procurement labels, and make sure the report explains both their function and the assurance evidence that supports the trust claim.

Related resources from NHI Mgmt Group

• When should organisations treat an NHI as a high-priority risk?
• How should security teams govern non-human identities for SOC 2 compliance?
• How do organisations operationalise NHI ownership at scale?
• How can organisations reduce the blast radius of compromised agent identities?