SOC 2 on a Neocloud: What Changes When You Move Off a Hyperscaler

A SOC 2 report survives a move from a hyperscaler to a neocloud, but its system description, boundary, vendor list and a set of controls change. The neocloud's own SOC 2 report covers the services the neocloud operates; the controls AWS, GCP or Azure handled through managed services, and the evidence a GRC platform pulled from their APIs, can become yours, depending on whether you rent managed Kubernetes, virtual machines or bare metal.

An AI lab asked this through a contact form after reading an article on SOC 2 for bare metal: what happens to SOC 2 if we move from a hyperscaler to a neocloud? The service model the team buys decides most of the answer.

What Is a Neocloud for SOC 2 Purposes?

A neocloud is a cloud provider focused on GPU compute for AI training and inference. Neocloud service models range from managed Kubernetes and virtual machines, where the provider operates the hypervisor and host, to bare metal servers, where the customer operates everything from the operating system up.

For SOC 2, a neocloud is a subservice organization: a separate company whose services are part of your system. Your system description names the neocloud, what it operates and the controls you expect it to perform. The carve-out and inclusive methods, complementary user entity controls (CUECs) and the annual review of the provider's report work the same way as for any data center; the guide to SOC 2 vendor management with a data center as a subservice organization covers them in full.

What Does a Neocloud's SOC 2 Report Cover, and Which Controls Move to You?

A neocloud's SOC 2 report covers the services the neocloud operates, and the service model decides how far up the stack that goes. With managed Kubernetes or virtual machines, the report can cover the facility, hardware, hypervisor and host. With bare metal, it typically stops at the facility, hardware and any out-of-band management the provider keeps.

Each neocloud draws the line in its own place, so confirm the split against the provider's SOC 2 report, CUEC list and contract.

The guide to complementary user entity controls in SOC 2 covers how to map each item on the neocloud's CUEC list to a control and its evidence.

What Breaks in Vanta or Drata Evidence After a Move to a Neocloud?

GRC platforms such as Vanta and Drata collect much of their infrastructure evidence through AWS, GCP and Azure API integrations: IAM users and MFA status, logging settings, security group rules and resource inventory. On a neocloud with no supported integration, those automated tests stop receiving data for the new environment, and each control needs another evidence source.

Integrations with the identity provider, HRIS and code repository keep working. Integration catalogs change, so check the platform's current list for the specific neocloud before cutover.

The guide to SOC 2 evidence without APIs covers scripted exports, CIS manual checks and dated records for infrastructure a GRC platform cannot read. The breakdown of what Vanta and Drata can't automate covers controls that need human-produced evidence anywhere.

What to Check in a Neocloud's SOC 2 Report and Contract Before Signing

A neocloud's trust package should show that its SOC 2 report covers the product, region and period you will use, and the contract should cover the bare metal risks the report leaves to you. CC9.2 asks for vendor requirements that include (1) scope of services and product specifications, (2) roles and responsibilities, (3) compliance requirements, and (4) service levels, so these items belong in the vendor file.

The CC9.2 vendor risk management guide covers how to tier the neocloud as a production vendor and what the annual review should contain.

Can You Move to a Neocloud in the Middle of a SOC 2 Type 2 Observation Period?

A migration to a neocloud can happen inside a SOC 2 Type 2 observation period, with planning. In practice, the system description covers both environments and the cutover date, and the auditor tests controls in each environment for the part of the period it operated. The AICPA description criteria (DC 200) include disclosure of significant changes during the period; the auditor confirms the wording.

A mid-period migration goes more smoothly with five practices:

• Talk to the auditor before the cutover date about how the change appears in the system description and which samples come from each environment.
• Schedule the migration before the window opens when possible, so there is one environment to describe and test.
• Keep evidence from the hyperscaler environment (logs, access reviews, change tickets) until the period ends and the report is issued.
• Scan the new hosts right after cutover. CC7.1 expects scans after significant changes to the environment.
• Record the exit from the hyperscaler. CC9.2 termination procedures may include safe return of data and its removal from the vendor or business partner system, so keep the deletion records for data, snapshots and accounts.

A logging or scanning gap on the new hosts during cutover week appears as an exception, so bring those controls up before production traffic moves.

How Does SOC 2 Scoping Work When Only GPU Workloads Move to a Neocloud?

SOC 2 scoping for a split setup treats the hyperscaler and the neocloud as one system with two subservice organizations. A common setup among AI companies keeps the control plane, customer data and identity on a hyperscaler and moves training or inference to a neocloud.

The boundary follows the data. If customer prompts, fine-tuning datasets or model weights trained on customer data reach the GPU nodes, those nodes are in scope. Data moving between the two clouds falls under CC6.7, which expects information to be protected during transmission, movement, or removal, so encryption in transit between environments needs evidence too.

GRC integrations keep covering the hyperscaler half, so engineered evidence is needed only for the GPU half. The SOC 2 scoping guide for hybrid infrastructure covers how to draw one boundary across a cloud control plane and a separate data plane.

Steps to Keep SOC 2 on Track During a Neocloud Migration

A team moving workloads to a neocloud can keep its SOC 2 program on schedule with eight steps:

1. Choose the service model and write down the responsibility split before signing.
2. Collect the neocloud's SOC 2 Type 2 report, bridge letter and CUEC list.
3. Add contract terms for drive disposal, BMC access, tenant reprovisioning and incident notification.
4. Add the neocloud to the vendor register and risk assessment as a production vendor under CC9.2.
5. Update the system description and boundary diagram, including the cutover date.
6. Build the controls that move to you. The SOC 2 for bare metal and on-prem infrastructure page lists the controls that change.
7. Replace API-sourced evidence with scripted exports and a collection calendar.
8. Agree timing with the auditor, scan after cutover and record the hyperscaler decommissioning.

SOC 2 on a Neocloud Comes Down to the Service Model and the Evidence Plan

A neocloud's SOC 2 report covers the neocloud. On managed Kubernetes the provider keeps most host controls; on bare metal the host and everything above it belong to your team, along with the evidence that proves them. Teams that settle the responsibility split, contract terms and evidence plan before cutover keep their next SOC 2 report on schedule, and with it the enterprise deals that depend on it.

Frequently Asked Questions

Does a neocloud's SOC 2 report cover our company?

No. A neocloud's SOC 2 report covers the services the neocloud operates, such as its facilities, hardware and, for managed Kubernetes or virtual machines, the hypervisor and host. Customers need a SOC 2 report on your own system, in which the neocloud appears as a subservice organization and its report supports your annual vendor review.

Do we need a new SOC 2 audit if we move to a neocloud?

The existing SOC 2 audit cycle continues, and the next report describes the new environment. Update the system description, boundary and subservice organization list, add the neocloud to vendor management, and build any controls the hyperscaler used to handle. If the migration happens mid-period, the report covers both environments and the cutover date.

Which controls move to us when we leave AWS, GCP, or Azure for a neocloud?

The service model decides. On managed Kubernetes or virtual machines, the neocloud usually keeps the hypervisor and host. On bare metal, you take on host patching and hardening (CC7.1), network segmentation (CC6.6), logging (CC7.2) and shared responsibility for firmware and BMC access, and you confirm drive disposal (CC6.5) in the contract.

Will Vanta or Drata still collect evidence after we move to a neocloud?

Partly. Integrations with the identity provider, HRIS and code repository keep working. Automated tests that read AWS, GCP or Azure APIs stop covering workloads on a neocloud with no supported integration, so access lists, asset inventory, hardening, scanning and logging need engineered evidence: scripted exports and dated records uploaded to the platform on a schedule.

Can we switch to a neocloud in the middle of a SOC 2 Type 2 observation period?

Yes, with planning. The system description covers both environments and the cutover date, and the auditor tests controls in each environment for the time it operated. Agree the approach with the auditor before cutover, keep evidence from the old environment, scan the new hosts after migration, and record how data was removed from the hyperscaler.