What should organisations include in a modern SOC 2 control scope?

Why This Matters for Security Teams

A modern SOC 2 control scope needs to reflect how systems actually operate now: cloud services, service accounts, secrets, APIs, automation, and AI features that process data outside the traditional login path. If the scope stops at human access reviews, it misses the identities and control points that are often the real path to data exposure. NHI Management Group notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is why the control boundary has to expand.

This is not just an NHI issue. SOC 2 reviewers increasingly expect evidence that controls cover the systems that store, move, and transform customer data, not only the people who administer them. The practical implication is that logging, change management, vendor oversight, and data protection controls must account for workload identities and AI-mediated workflows. Current guidance suggests aligning the scope to actual data flows and decision points, then proving those controls operate continuously rather than only during audit prep. For a deeper baseline, see the Ultimate Guide to NHIs — Key Challenges and Risks and the OWASP Non-Human Identity Top 10.

In practice, many security teams discover the scope gap only after a vendor integration, service account, or AI workflow has already moved sensitive data outside the controls they believed were in place.

How It Works in Practice

Modern SOC 2 scoping starts with a system inventory that goes beyond endpoints and user groups. It should include applications, SaaS tools, CI/CD pipelines, service accounts, API keys, secrets managers, model endpoints, prompt-processing layers, and the storage locations where logs and training inputs are retained. The aim is to identify where Trust Services Criteria can fail in real operations: access, change control, confidentiality, availability, and monitoring.

A useful scoping method is to map each system to the data it touches and the identities it uses. That means asking which workload or agent can read, write, call, delete, or export data; which secrets authorize those actions; and which logs prove they occurred. For AI-enabled environments, the scope should also include prompt injection handling, output filtering, model access controls, and immutable logging where decisions are materially influenced by AI. The NIST AI Risk Management Framework is useful here because it treats governance, mapping, measurement, and management as operational functions, not documentation exercises. See the Ultimate Guide to NHIs — Standards alongside the OWASP Non-Human Identity Top 10.

• Include workload identities, not just employee identities.
• Scope secrets storage, rotation, and offboarding as auditable controls.
• Cover AI prompts, model inputs, and output review where they affect customer data.
• Require immutable or tamper-evident logs for high-impact actions.
• Extend vendor scope to subcontractors and integrations that process in-scope data.

The control set should also define evidence collection up front: access logs, rotation records, exception approvals, incident alerts, and configuration baselines. These controls tend to break down in hybrid environments where legacy systems, shadow IT, and machine-to-machine integrations share the same data paths but are governed by different teams.

Common Variations and Edge Cases

Tighter scope often increases audit overhead and operational friction, requiring organisations to balance completeness against the cost of evidence collection. That tradeoff is real, especially when AI features are embedded inside products rather than deployed as separate systems. Best practice is evolving, and there is no universal standard for this yet, so teams should document the rationale for inclusion and exclusion instead of assuming the auditor will infer it.

One common edge case is a shared platform where multiple customers, models, or pipelines use the same identity infrastructure. In those environments, scope should include the identity controls, logging, and segregation mechanisms that prevent cross-tenant access, even if the product team sees them as backend details. Another edge case is third-party AI services that store prompts or training data: the service may be external, but the SOC 2 boundary still needs to include the decision to send data there, the contract terms, and the monitoring for misuse. The strongest evidence comes from showing that the control owner can explain how an event would be detected, contained, and revoked across both human and machine actors.

If the organisation uses ephemeral agents, just-in-time credentials, or automated pipelines, the scope should reflect those runtime controls rather than relying on static access lists. In practice, auditors tend to push back when the scope omits machine identities that can read production data or issue customer-facing actions, because those omissions undermine the trust boundary the report is meant to describe.

Related resources from NHI Mgmt Group

• What do organisations get wrong about access control compliance?
• What should organisations do when a control is documented but hard to evidence?
• How can organisations control mailbox forwarding risk in Exchange Online?
• How should security teams govern non-human identities for SOC 2 compliance?