SOC 2 for Hybrid and On-Prem Infrastructure: Scoping and the System Description

A service that runs partly in a public cloud and partly on company-owned hardware is one system for SOC 2 whenever customer data or commands cross between the two. The SOC 2 hybrid on-prem scope follows that data flow as one boundary, and one SOC 2 system description names the components on each side, how they connect, which subservice organizations are carved out, and what customers handle themselves.

What counts as one system for SOC 2 in a hybrid cloud and on-prem setup?

A SOC 2 system for a hybrid setup is everything that delivers the service customers rely on, wherever it is hosted. The AICPA Trust Services Criteria define system boundaries as the specific aspects of an entity's infrastructure, software, people, procedures, and data necessary to perform a function or provide a service. A cloud application that sends customer jobs to servers in a colocation rack is one service, so it is one system.

Hybrid setups we see in SOC 2 readiness work usually fall into one of four arrangements:

• Cloud front end, on-prem processing: the customer-facing application and API run in AWS, GCP, or Azure, and compute-heavy or data-sensitive processing runs on company hardware
• Cloud control plane, on-prem data plane: the cloud schedules work and stores configuration, and on-prem compute runs it, whether that is VMs on VMware or Proxmox, bare-metal servers, or an on-prem Kubernetes cluster
• On-prem core, cloud services around it: the main application runs in a company data center, with backups, disaster recovery, or monitoring in the cloud
• Corporate SaaS in every case: code hosting, identity and SSO, and an HRIS that controls who has access to both sides

A cloud-only SOC 2 scope for any of these leaves the system description inaccurate, because customer data reaches the on-prem side.

How to draw the SOC 2 boundary for a hybrid system as a data flow

The SOC 2 boundary for a hybrid system is easiest to defend when it is drawn as a data flow: follow customer data and customer commands from entry to storage to deletion, and every component they touch is in scope.

Three questions settle most hybrid boundary decisions:

1. Does customer data pass through it, rest on it, or get processed by it? If yes, it is in scope.
2. Can it change what runs in production? CI/CD pipelines, artifact and image registries, infrastructure-as-code repos, and the admin path into on-prem hosts are in scope because they control the production environment. The SOC 2 SDLC guide for self-hosted GitLab covers change control for that path.
3. Is it operated by another company under its own controls? The cloud provider and a colocation facility are subservice organizations, and most hybrid reports carve them out.

The SOC 2 CC2.1 point of focus on managing assets expects the entity to identify, document, and maintain records of system components, including physical endpoint devices and systems, virtual systems, data and data flows, and external information systems. An inventory that lists only cloud resources leaves the on-prem half of those records empty.

When the on-prem side of a hybrid system can be left out of SOC 2 scope

The on-prem side of a hybrid system can stay out of SOC 2 scope only when customer data and the service commitments do not depend on it. On-prem hardware used for isolated internal work, with no production data, no shared credentials, and no deployment path into production, is a reasonable exclusion. If data or commands cross the boundary between cloud and on-prem, the on-prem hardware is part of the system.

In hybrid companies, the on-prem side often hosts the build environment: a toolchain or firmware team working on lab hardware whose output goes into the product. That team is part of the SDLC that CC8.1 covers, since CC8.1 addresses how the entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures. In a recent engagement, a hardware company asked to exclude an internal toolchain group and its on-prem build environment; the advice was to keep them in, because the auditor traces in-scope software back through review, testing, and approval.

The SOC 2 scope guide to systems, people, and processes covers the general exclusion rules for dev and test environments, business units, and the compliance population.

SOC 2 hybrid scoping table: component, location, and evidence source

A component-level scoping table turns the SOC 2 boundary for a hybrid system into a work plan, one row per component.

How to write the SOC 2 system description for a hybrid cloud and on-prem system

The SOC 2 system description for a hybrid system is one narrative covering both hosting environments, written so a customer can follow their data from the cloud to company hardware and back. The AICPA description criteria (DC 200) set what the description discloses. The table below summarizes the main DC 200 disclosures and what each one means at a hybrid boundary; the AICPA publication holds the full wording, and the service auditor confirms how it applies to a given report.

Four writing choices make a hybrid system description easier to test:

• Describe infrastructure by function, then by location, so the reader follows a job from the cloud application to the on-prem server that processes it.
• State how the two sides connect. Name the mechanism, who can change it, and how changes are approved.
• Write each control with its location. Access review, patching, and logging controls should say whether they cover the cloud, the on-prem hardware, or both.
• Match the architecture diagram. Every component in the diagram appears in the description, and every component in the description appears in the diagram.

How cloud provider and colocation SOC 2 reports fit a hybrid system description

A cloud provider's SOC 2 report covers the provider's own infrastructure under the shared responsibility model, and a colocation facility's report covers the building, power, cooling, and physical access. The hybrid system description treats both as subservice organizations, usually with the carve-out method. Cloud account configuration, identity and access management, logging, encryption settings, and backups stay with the company, and the auditor tests them as the company's controls.

The SOC 2 vendor management guide for data centers as subservice organizations covers carve-out and inclusive methods, complementary user entity controls, and what to request from the provider. The guide to SOC 2 on a neocloud covers what changes in that split when the cloud side moves off a hyperscaler.

SOC 2 evidence for the on-prem half of a hybrid system

GRC platforms such as Vanta and Drata collect evidence from cloud accounts, identity, code, and HR tools through integrations, and the on-prem half of a hybrid system needs evidence the team produces itself. The GRC compliance guide for on-prem and hybrid environments covers the inventory-first approach that brings on-prem tests into the same evidence library, and the guide to SOC 2 evidence collection without APIs covers the evidence artifacts for hypervisors, firewalls, and servers patched by hand.

Vulnerability scanning is a frequent hybrid gap: in a recent engagement with a hardware company, the cloud side had scanning coverage and the on-prem environment had none. The CC7.1 points of focus include vulnerability scans on a periodic basis and after significant changes, so the auditor can sample on-prem hosts. The SOC 2 vulnerability scanning guide for on-prem servers covers tiers, tools, and cadence.

SOC 2 timeline for hybrid infrastructure: build first, then observe

A SOC 2 Type 2 timeline for a hybrid environment has two phases: build the security program, then operate it through an observation period.

The AICPA sets no minimum observation period, and in practice many auditors and customers expect at least three months for a first Type 2. The build phase can be compressed when the engineering team responds quickly and the on-prem evidence jobs are built early, because the observation period cannot start until the controls exist.

How to apply SOC 2 hybrid scoping to an existing environment

Five steps take a hybrid environment to an auditable SOC 2 boundary and system description:

1. Map the data flow. Trace customer data and commands from entry to deletion across cloud and on-prem, and mark every component they touch.
2. Fill in the scoping table. One row per component with location, scope decision, evidence source, and known gap.
3. Decide the subservice treatment. List the cloud provider, colocation facility, and any managed services, and confirm which are carved out and which controls the company relies on them to operate.
4. Build the on-prem evidence jobs before the observation period opens, so evidence covers the full period.
5. Write the system description last, from the data flow and the scoping table, so it matches what the auditor will test.

Identity is a control that often splits along the hybrid line. The guide to centralized identity in hybrid security architecture covers bringing local on-prem accounts under the same SSO as the cloud.

A hybrid SOC 2 scope that holds up to auditors and customers

A hybrid SOC 2 scope holds up when the boundary follows the data, the system description matches the architecture, and every in-scope control states where it operates. Companies that settle the boundary and the description before the observation period opens get a report that matches where customer data goes, which keeps enterprise security reviews moving.

Frequently Asked Questions

How do we scope SOC 2 when our control plane is in the cloud and our data plane is on-prem?

Scope both halves as one system. Customer data and commands flow between the cloud control plane and the on-prem data plane, so the SOC 2 system description covers both, with one boundary drawn along the data flow. Map each control to where it operates, and carve out the cloud provider and colocation facility as subservice organizations.

What goes in the SOC 2 system description for a hybrid environment?

A SOC 2 system description for a hybrid environment covers the services, service commitments, and system components on both the cloud and on-prem sides; how data moves between them; the controls, mapped to where each operates; subservice organizations such as the cloud provider and colocation facility; complementary user entity controls; and, for a Type 2, significant changes during the period.

Can we leave the on-prem half of a hybrid system out of SOC 2 scope?

Only if customer data and the service commitments do not depend on it. On-prem hardware used for isolated internal work, with no production data, shared credentials, or deployment path into production, can stay out. If customer data or commands cross the boundary between cloud and on-prem, the on-prem half is part of the system.

Does our cloud provider's SOC 2 report cover the cloud half of a hybrid system?

It covers the provider's own infrastructure under the shared responsibility model, and the system description treats the provider as a subservice organization, usually carved out. Cloud account configuration, identity and access management, logging, encryption settings, and backups stay with the company, and the auditor tests those controls directly.

Can we change infrastructure in the middle of a SOC 2 Type 2 observation window?

Yes. The AICPA description criteria require a Type 2 system description to disclose significant changes during the period, so the migration goes into the description. Controls must operate in both the old and new states, and evidence must cover both. Scheduling a large migration before the window opens keeps testing to one state.