How should software companies scope SOC 2 without overloading the audit?

Why This Matters for Security Teams

Soc 2 scope is not just an audit convenience question. It determines which systems must be controlled, evidenced, and monitored, which in turn affects cost, timeline, and the credibility of the final report. If the boundary is too broad, teams drown in low-value evidence requests. If it is too narrow, the report can miss systems that influence production risk or customer data handling. Current guidance suggests focusing on the trust boundary, not every internal asset.

That discipline matters because control failures often originate in places teams do not initially consider in scope, such as build pipelines, support workflows, or service accounts. NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives makes the same point from an identity angle: when non-human identities are invisible, audit boundaries become unreliable. The broader lesson aligns with the OWASP Non-Human Identity Top 10, which treats unmanaged machine identities as a real security exposure, not a paperwork issue. In practice, many security teams discover an oversized scope only after evidence collection has already become unmanageable, rather than through intentional boundary design.

How It Works in Practice

The most defensible way to scope Soc 2 is to start from the services that process customer data, deliver the product, or directly influence security outcomes, then trace dependencies outward until the evidence burden no longer changes the control story. That usually means including production systems, identity infrastructure, logging, ticketing paths that can change access, and cloud resources that store or move in-scope data. It usually means excluding internal experimentation, isolated development tools, and office productivity systems unless they directly touch customer data or production authorization.

Practitioners should document the rationale for each inclusion and exclusion. This is where scope control becomes auditable rather than subjective: map systems to trust services criteria, identify where evidence will be collected, and show why each boundary is necessary. NHIMG’s NHI Lifecycle Management Guide is useful here because it reinforces a practical rule: if a system can create, use, rotate, or revoke access to in-scope resources, it may be part of the control environment even if it is not customer-facing. That approach also fits the NIST Cybersecurity Framework 2.0 emphasis on governance, access control, and asset visibility.

• Define the in-scope data sets first, then attach systems to those data paths.
• Include production-adjacent tooling if it can change access, deployments, or data flow.
• Keep development sandboxes out unless they contain live customer data or production secrets.
• Document shared services, external dependencies, and compensating controls.

This guidance breaks down in heavily shared platforms where internal and customer-facing functions run on the same infrastructure, because evidence and control ownership become difficult to separate cleanly.

Common Variations and Edge Cases

Tighter scope often reduces audit cost, but it can also create more debate about what counts as operationally relevant, so organisations have to balance simplicity against defensibility. The hardest cases are usually shared services, multi-tenant architectures, and product-led growth companies where support, billing, and engineering tools overlap. In those environments, a narrow scope can fail if a supposedly “internal” system can still alter customer access, modify production settings, or expose secrets.

Current guidance suggests treating those overlaps as boundary questions, not exceptions to be ignored. If a change in an internal system can affect confidentiality, integrity, or availability of the customer environment, it should usually be mapped into the control narrative even if the system itself is not customer visible. NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is relevant because scope problems often trace back to unmanaged machine access, while the article’s data point that only 5.7% of organisations have full visibility into service accounts shows why hidden dependencies are so common. For teams looking to tighten scope without missing risk, the practical test is simple: if the system can change who can reach in-scope data, it is probably in scope.

There is no universal standard for every edge case, so auditors usually expect consistent reasoning, written criteria, and proof that exclusions do not undermine the control environment.

Related resources from NHI Mgmt Group

• Why does scope definition matter so much in a SOC 2 audit?
• SOC 2 Audit Scope
• How should security teams run access reviews without creating audit theatre?
• Who should own identity evidence for a SOC 2 audit?