Can You Leave an Internal Team Out of SOC 2 Scope? Dev Servers, CI/CD, and the Carve-Out Question

SOC 2 scope can leave out development and test servers, but it includes the source code repository, the CI/CD pipeline and any internal team whose code reaches production. Auditors follow every path that can change the production system, and an internal team that releases into production is on that path.

A compute infrastructure company brought this question to a scoping call. Besides its product team, it has an internal compiler team that releases into production frequently, so production depends on that team's development process. The cloud ops lead asked: is that team's SDLC in scope, are its build and test environments in scope, and would a creative carve-out cause trouble later with auditors, customers or partners who read the report?

Which Parts of a Software Delivery Chain Are in SOC 2 Scope?

The parts of a software delivery chain that can change production are in SOC 2 scope; the places where engineers experiment are outside testing.

The guide to SOC 2 scope across systems, people and processes covers general scoping.

Why Development and Test Servers Stay Outside SOC 2 Testing

Development and test servers stay outside SOC 2 testing when they hold no production data and have no route into production. In the audits we support, auditors do not check whether a developer's test server is patched, because nothing on that server reaches customers until it passes through the pipeline.

Production data copied into a test database, a shared service account, or a test server that can push to production each pull the environment back into scope. The hybrid on-prem scoping guide applies the same test to on-prem hardware.

Why the Repository and CI/CD Pipeline Are in SOC 2 Scope

The source code repository and the CI/CD pipeline are in SOC 2 scope because they produce what reaches production. CC8.1 in the 2017 Trust Services Criteria expects the entity to authorize, design, develop or acquire, configure, document, test, approve and implement changes to infrastructure, data, software, and procedures, and the pipeline is where most of those steps happen.

Build runners, artifact registries, deployment tooling and infrastructure-as-code repositories are on the same list. A self-hosted repository adds the server itself, as the guide to SOC 2 secure development with self-hosted GitLab describes.

Why an Internal Team That Releases Code to Production Is in SOC 2 Scope

An internal team that releases code into production is in SOC 2 scope, because its development process is part of the system's change management. Production depended on the compiler team's releases, so its repository, reviews, tests and deployment approvals are inside the boundary the auditor tests under CC8.1.

Auditors trace every dependency in the chain that could affect the criteria. External dependencies, such as the cloud provider and the data center, are covered through their own SOC 2 reports, as the guide to data centers as subservice organizations explains. Internal teams get the same scrutiny, and with no report of their own, their controls are tested directly. The company in the scoping call concluded that the compiler team had to be in scope.

How SOC 2 Treats a Separate Company Versus an Internal Team

SOC 2 lets a company scope out another company through a contract; an internal team has no equivalent route. If the compiler team were a separate company, its code would arrive as a vendor deliverable, managed as third-party risk under CC9.2 with contract terms for secure development and change control, as the CC9.2 vendor risk management guide describes.

The SOC 2 carve-out method is also built for separate companies: it excludes the controls of a subservice organization, such as a cloud provider, as the guide to the carve-out versus inclusive method explains. An internal team is part of the service organization, so the carve-out method does not apply to it.

What Customers See When a SOC 2 Report Leaves a Team Out

Customers see the SOC 2 scope in the system description, which states what the report covers. The AICPA 2018 SOC 2 Description Criteria (With Revised Implementation Guidance, 2022) ask the description to set out the components of the system in DC 3: infrastructure, software, people, procedures and data.

A description that leaves out a team on the production release path is hard to explain. Sophisticated customers read system descriptions, notice the gap and follow up with security questionnaires about the excluded team, each needing evidence outside the report. The guide to security questionnaire automation covers how those follow-ups add up.

Which People a SOC 2 Scope Can Leave Out

A SOC 2 scope can leave out staff who have no access to in-scope systems, and it always includes leadership. Leadership sets the control environment under CC1, so executives stay in scope even when they never touch production.

Working-level staff who do not touch production, such as a walled-off research group or a government-services team, can be segmented out of system-level controls like device management and access review sampling. Company-wide controls, including policy acceptance and security awareness training, still apply to everyone. The SOC 2 people scoping guide covers grey-area roles such as support, HR and finance.

Name the excluded group to the auditor early and enforce the separation in identity provider groups.

How a Fast-Moving Engineering Team Meets SOC 2 Change Management

A team that releases often can meet SOC 2 change management with automated approval for low-risk changes and human review where risk is higher:

• Low-risk merges are approved automatically when the full automated test suite passes, with the pipeline log as the approval record.
• Security-sensitive changes, such as authentication and authorization code, get human review, either before merge or in a periodic review agreed with the auditor.
• The policy defines both categories, so the auditor can test the rule against a sample.

Agree the design with the auditor before the observation period starts. The CC8.1 change management guide lists the points of focus, and the guide to change management with tickets covers teams that release through a ticket workflow.

Steps to Decide Whether an Internal Team Belongs in SOC 2 Scope

1. Map the release path from commit to production, naming every team that can change production.
2. Mark each environment by data and access: production data, shared credentials, deployment rights.
3. Place every team on the release path in scope, with its repository, pipeline and approvals.
4. Move outside companies to vendor management with contract terms under CC9.2.
5. List walled-off groups and enforce their separation in the identity provider.
6. Write the system description so a customer can match the release path to the teams in scope.

The SOC 2 for bare metal and on-prem infrastructure page covers these steps for compute and AI infrastructure companies.

A SOC 2 Scope That Includes the Release Path Holds Up With Customers

A SOC 2 scope that includes every team on the release path gives customers a report they can match to how the product is built. Development servers stay light, the pipeline carries the controls, and security reviews stay short, which keeps deals moving.

More on-prem SOC 2 guides: the full on-prem security program checklist, Processing Integrity for compute providers and what Vanta and Drata automate on-prem.

Frequently Asked Questions

Are development environments in scope for SOC 2?

Development and test environments stay outside SOC 2 testing when they hold no production data, share no credentials with production and have no deployment path into production. If any condition fails, the environment is back in scope. The repository and CI/CD pipeline that carry code to production are in scope.

Is GitHub in scope for SOC 2?

Yes. GitHub, GitLab or any repository holding production code is in SOC 2 scope. Auditors look at branch protection, write and admin access, periodic access reviews and a sample of pull requests with their approvals. A self-hosted instance adds the server's patching, backups and logging.

Is the CI/CD pipeline in scope for SOC 2?

Yes. The CI/CD pipeline, build runners, artifact registry and deployment tooling are in SOC 2 scope because they build and deploy production artifacts. CC8.1 covers testing, approving and implementing changes, and auditors also check who can edit the pipeline configuration.

Can we exclude a subsidiary or team from SOC 2?

A separate company, including a subsidiary that operates as its own entity, can be managed as a vendor through its contract under CC9.2. An internal team that releases code into production is part of the system and is in scope. Teams with no access to in-scope systems can be left out of system-level controls.

Do contractors count as in scope for SOC 2?

Contractors with access to in-scope systems are in SOC 2 scope, the same as employees: onboarding, access reviews, policy acceptance and offboarding apply. A contracting firm that delivers code is also managed as a vendor under CC9.2.

Will customers see what we excluded from SOC 2 scope?

Customers see the scope in the system description, which sets out the infrastructure, software, people, procedures and data the SOC 2 report covers. A gap between the release path and the teams in scope draws follow-up security questionnaires, each needing evidence outside the report.

Can low-risk code changes skip manual approval in SOC 2?

Low-risk changes can be approved automatically when the test suite passes, if the change management policy defines low-risk changes and the pipeline log records the result. Security-sensitive code, such as authentication and authorization, keeps human review. Agree the design with the auditor first.

Can the SOC 2 carve-out method be used for an internal team?

No. The carve-out method applies to subservice organizations: separate companies, such as a cloud provider or data center, with their own controls and SOC 2 reports. An internal team is part of the service organization, so its controls are tested directly.