Who is accountable when a company scopes the wrong SOC 2 criteria for its risk profile?

Why This Matters for Security Teams

Scoping the wrong SOC 2 criteria is not just a reporting mistake. It changes which risks are measured, which controls are tested, and which gaps remain invisible to leadership. That matters because SOC 2 is often used as evidence of trust in procurement, partner onboarding, and board reporting. If the scope does not match the actual operating risk, the organisation may produce a clean report while still carrying unmanaged exposure.

Accountability sits with the service organisation, not the auditor. Auditors assess whether the selected criteria are applied consistently and whether evidence supports the stated scope, but they do not define the risk appetite or operating model. That decision should reflect the business, its systems, its data flows, and its dependencies. Current guidance around control selection aligns well with the control intent in NIST SP 800-53 Rev 5 Security and Privacy Controls, which reinforces the need to match controls to actual risk conditions.

In practice, many security teams encounter scope failure only after a customer asks a hard question, rather than through intentional risk-based scoping.

How It Works in Practice

In a sound SOC 2 scoping process, leadership defines the service commitments, data handling boundaries, supporting infrastructure, and material third-party dependencies before the audit period starts. Compliance owners then translate that business context into Trust Services Criteria that reflect actual exposure. Control operators provide the evidence that those controls are designed and operating effectively. When those roles blur, the result is usually either under-scoping, which hides important risk, or over-scoping, which creates cost and noise without improving assurance.

The practical question is not simply which criteria can be included, but which criteria are necessary to describe the service honestly. Security teams often use a control baseline from NIST Cybersecurity Framework 2.0 to structure the risk conversation, then map evidence to the SOC 2 criteria most relevant to confidentiality, availability, processing integrity, privacy, or security. That mapping should include identity and privileged access dependencies, especially where non-human identities, service accounts, and API tokens are involved. The OWASP Non-Human Identity Top 10 is useful here because poorly governed machine credentials are a common source of hidden control failure.

A disciplined process usually includes:

• a documented risk assessment tied to the service architecture and customer commitments
• clear ownership for scope approval, usually in security, compliance, and executive leadership
• control mapping that distinguishes enterprise controls from product-specific controls
• evidence reviews that confirm the control actually operates in the environments in scope
• periodic scope refresh when systems, vendors, or data use change

Threat context also matters. If the organisation’s attack surface is expanding through cloud services, exposed secrets, or agentic automation, the scope should reflect those realities rather than legacy assumptions. External threat analysis such as the ENISA Threat Landscape can help justify why certain control families belong in scope. These controls tend to break down when the company has multiple product lines with different data sensitivities but applies one generic scope statement across all environments.

Common Variations and Edge Cases

Tighter SOC 2 scoping often increases audit effort, operational overhead, and evidence collection cost, requiring organisations to balance assurance value against reporting simplicity. That tradeoff is real, especially for fast-growing companies and platforms with shared infrastructure. The safest answer is not always the narrowest scope; it is the scope that most accurately represents customer risk without pretending the rest of the environment does not matter.

There is no universal standard for how aggressively to expand scope when a company uses shared services, outsourced operations, or heavy automation. Best practice is evolving for agentic workflows and non-human identities, because the control owner may be a platform team, an application team, or a central identity function depending on how credentials and approvals are managed. Where machine identities can create, rotate, or use secrets without direct human action, the scoping decision should explicitly reflect that governance layer rather than assuming traditional user-based access models are enough.

Scope errors also show up when a company treats one audit period as reusable across major architecture changes. That is risky. New cloud regions, new subprocessors, new data classes, or new AI-enabled features can change the control environment materially. In those cases, accountability remains with leadership to reopen the scoping decision and document why the selected criteria still fit. The report may still be valid as a historical statement, but it may no longer be a good description of the current risk profile.

Related resources from NHI Mgmt Group

• Who is accountable when a risk-based access decision is wrong?
• Who is accountable when an embedded AI feature changes a vendor risk profile?
• Who is accountable when an AI SOC platform takes the wrong action?
• Who is accountable when an AI SOC auto-closes the wrong case?