Scoping Out Development Environments From SOC 2 Audits

"Can we just exclude dev?" is usually the first question a team asks once a SOC 2 audit comes into view, and it is usually asked of the wrong department. The answer does not live in a policy template or a legal opinion. It lives in how the development environment is actually wired: what it can reach, what credentials it holds, and what would happen if someone compromised it tomorrow. SOC 2 scope is the boundary around what a company needs to deliver its service and meet its commitments to customers. Whether a dev environment falls inside or outside that boundary is a question for the people who built the environment, not the people who write about it.

What SOC 2 scope covers

Scope follows the path a service actually takes to reach a customer, and anything sitting outside that path is a candidate for exclusion rather than something that gets pulled in by default. SOC 2 tightened its rules compared to earlier standards, but the job of drawing the boundary still falls to company management; an auditor's job is to test whether that boundary makes sense and whether it has been described honestly. The AICPA breaks any in-scope system into five pieces: infrastructure, software, people, procedures, and data, so scope is a judgment made across all five, not a decision about which servers to list. Once a service is ruled in scope, every relevant piece of it comes along too. A company can choose which services or environments to include, but it cannot reach into a chosen service and pick out only the convenient parts.

Dev environments sit right at the edge of this boundary because they are not hypothetical or abstract. They run on real infrastructure, staffed by real people holding real credentials, and in that sense they look a great deal like production. What usually separates them from production, when they are managed correctly, is that they never touch customer data and never deliver the service to anyone outside the company. CodeLynks' scoping guide offers a useful parallel: a mid-sized company auditing a collaboration platform excluded its European offices, because those teams worked on marketing and business development and had no access to production systems or data. The same reasoning applies to a dev environment with no path into production: the exclusion rests on an absence of access, not on where the work happens to sit on an org chart.

Security is the only mandatory Trust Services Criterion, while Availability, Processing Integrity, Confidentiality, and Privacy are scoped in based on what the business does and what customers expect, and Security controls still apply to whatever is kept in scope. Security evidence is also the standard a dev-environment exclusion has to satisfy. If a company cannot show that access controls hold at the dev/production line, no amount of reasoning about customer expectations or service design will save the exclusion.

The three technical conditions that make a dev-environment exclusion defensible

No production data in dev, no shared credentials between environments, and no access path from dev tooling into production must all hold simultaneously for a dev-environment carve-out to survive auditor scrutiny. A team that nails isolation on network access but still copies customer records into a staging database for testing has not earned an exclusion. It has just moved the problem.

The first condition concerns data. If real customer data has ever been copied into a dev or test environment, even once, for even a reasonable-sounding testing purpose, that environment stops being cleanly excludable. The data boundary follows wherever the data actually is, not whatever label sits on the environment. This is a common trap: some organizations decide to pull dev and test environments into scope because those environments were built to "mirror production" closely. The better fix is making sure those mirrored environments never hold real customer data in the first place, so inclusion stops being treated as the solution to what is really a data-hygiene failure.

The second condition concerns credentials. Production server credentials cannot be shared with staging or dev, and this is not something an auditor takes on faith from a document. It gets checked technically, by looking at who holds what access and where those credentials are used. Network isolation has to actually stop staging systems from writing into production databases by accident, and that, too, is a technical test rather than a written assurance.

The third condition concerns access paths. Developers who log into production to debug something, secrets managers shared across environments, and infrastructure-as-code templates that spin up both dev and prod resources from the same definitions all blur a boundary that is supposed to be sharp. Every one of these patterns is checkable in the environment itself. An auditor who wants to confirm the boundary holds does not read the policy that describes it. They look for the technical enforcement that makes the policy true.

Where the boundary breaks in practice

Modern engineering practice tends to work against a clean dev/production split, in ways that never appear in a scope document but become visible as soon as someone looks at the actual environment. The test for each pattern below is the same one that governs the three conditions above: does this create a path from dev into production data? Where the answer is yes, the exclusion argument fails at that specific point, regardless of how well everything else is documented.

CI/CD pipelines are one of the most common failure points, because the deployment tool itself usually holds direct write access to production servers. DeployHQ's analysis of SOC 2 audit outcomes found that access control weaknesses tied to criteria CC6.1 through CC6.8 account for roughly two-thirds of qualified opinions, and the deployment tool is often the weakest link precisely because of that production write access. A company can exclude its dev environment and still leave its pipeline ungoverned, and that ungoverned pipeline recreates the same production-access risk through a side door. Excluding dev does nothing to exclude the tool that connects dev to production.

Shared secrets create a nearly identical problem. Backups, exported data sets, and analytics copies pulled from production are often left unencrypted in the process, and auditors now test encryption coverage across every in-scope data store, not only the primary production system.

Vendor relationships add a third layer. Teams increasingly rely on AI coding assistants, contractor platforms, and outside development services that touch source repositories or build pipelines directly. Where those vendors hold the same credentials or tokens that reach production, the isolation argument stops breaking at the edge of the company and starts breaking at the edge of the vendor relationship. A rough but useful way to think about the scale of this risk: a meaningful share of organizations now run at least one third-party integration with this kind of reach into their build or deployment process.

The breach record on declared but unenforced boundaries

When a company writes down a dev/production boundary but never actually enforces it technically, attackers tend to find the gap before any auditor does, and they walk through it using exactly the paths that would have failed a technical audit test.

LastPass's 2022 incident illustrates the credential and access-path conditions failing together. An attacker got into part of LastPass's development environment and pulled out source code repositories, technical documentation, and an encrypted copy of the key used to protect backups of customer data stored in Amazon S3. A second, related incident followed: a senior DevOps engineer's personal computer was compromised, a keystroke logger planted through a remote code execution flaw captured that employee's master password, and the attacker used it to reach an internal vault holding further keys. The dev environment in this case was never an island. It held material that connected directly to production-adjacent data, no matter how the company's scope document described the relationship between the two.

Uber's breach shows the access-path condition failing in its purest form. Attackers reached a server holding personally identifiable information by first getting into Uber's code repository, which held the login credentials needed to reach Uber's production environment. A code repository is exactly the kind of dev-side asset most companies would want to classify as excludable. Here, it was the direct route into production.

The most recent case, and the sharpest illustration of the vendor-trust-chain failure, involves Vercel. Beginning around February 2026 and disclosed that April, attackers used a compromise of Context.ai's Google Workspace OAuth tokens to gain a foothold in Vercel's internal systems. The attack exposed non-sensitive environment variables for a limited subset of customer projects after a Context.ai Google Workspace OAuth integration used by a Vercel employee was compromised, letting attackers pivot into Vercel's internal systems and read environment variables not marked as sensitive. This is the vendor trust chain failure described above, now documented rather than hypothetical: the boundary did not break inside the dev environment itself. It broke at the credential that connected a vendor's authentication system to Vercel's internal one.

How auditor scrutiny of dev-environment exclusions has tightened

The rulebook itself has stayed stable. The 2017 Trust Services Criteria, with points of focus revised in October 2022, remain the operative standard in 2026. What has changed is how much proof an auditor now expects before accepting an exclusion, backed by evidence rather than a stated policy. SureCloud's 2026 SOC 2 guide notes that static screenshots are increasingly challenged as evidence.

The institutional signal backing this up came from the AICPA Peer Review Board, which issued guidance in May 2026 directing reviewers to examine SOC 2 engagement risk more closely. It is the evidence bar rising to match the sophistication of the risk auditors have watched play out in public. An exclusion that would have passed in 2022 on a documented policy and a network diagram now needs the same underlying claims delivered differently: machine-readable, time-stamped, and continuous rather than static. Auditors have seen what happens when a declared boundary turns out not to be enforced, in cases like LastPass, Uber, and Vercel, and they now test specifically for the conditions that let those failures happen.

The strategic cost of getting the scope wrong in either direction

Scope is not something a company can afford to set conservatively wide and call safe. Drawing the line too broadly and drawing it too narrowly both carry real, measurable costs, and the right answer is whichever boundary actually matches how the service is delivered, backed by technical enforcement rather than a cautious guess.

Over-scoping compounds in ways that are easy to underestimate going in. Scrut documents four effects that stack on top of each other: controls scale with every system pulled into scope, the evidence burden multiplies right along with them, the audit timeline stretches as complexity grows, and more people across the company end up pulled into the process to match the expanded boundary. A 50-person company whose product runs on a 10-person engineering team gains nothing by running access reviews, endpoint management, and audit testing against the other 40 employees who have no bearing on service delivery. Worse, an over-scoped first audit tends to set the baseline for every audit that follows. Narrowing scope in year two becomes its own project, one that invites the question of what changed and why, rather than a simple correction.

Under-scoping carries a different kind of cost, one that appears later in procurement and often hits harder. Enterprise buyers read SOC 2 reports line by line during procurement, and a scope carve-out that excludes a system clearly relevant to their data raises exactly the kind of question that undercuts the value of the whole report. A-LIGN's 2024 Compliance Benchmark Report, cited by Pease Bell, found that a growing share of companies reported losing deals specifically because they lacked a certification a buyer required. That pressure is building. A scope that was perfectly defensible when a company raised its Series A may fail to satisfy the procurement team evaluating it at Series B, and reworking scope in the middle of an audit cycle ranks among the most expensive corrections a company can make in the entire readiness process. The dev-environment exclusion is worth making exactly when the three conditions described earlier hold up under technical inspection, and worth abandoning the moment any one of them does not.

Building and documenting a dev-environment exclusion that holds through the audit

Building an exclusion that survives an audit starts with treating the three conditions as engineering requirements rather than compliance language. Credential separation needs to be provable through access logs or identity provider exports showing that dev and production credentials were never shared or reused across the audit period. Network isolation needs to be provable the same way: not a diagram showing how things are supposed to connect, but logs or configuration exports showing that no path from dev to production existed while the audit clock was running. The absence of production data in dev needs to rest on data classification and handling records that show where real customer data has and has not traveled. And the CI/CD pipeline connecting the two environments needs its own governance story, because a clean dev environment sitting behind an ungoverned deployment tool does not actually close the gap that auditors, and attackers before them, have learned to look for.

None of this is paperwork laid on top of an engineering decision. It is the engineering decision, written down in the form an auditor can verify.