How to Read SOC 2 Reports for Enterprise GPU Hosting

A SOC 2 for GPU hosting is a CPA attestation on a named service organization’s controls, not a gold sticker for every AI feature on the website. You read it to see what was tested, for which period, and what was left outside the system description.

Reading a SOC 2 for GPU hosting is the work of matching the report’s system description, complementary user entity controls, and exceptions to the GPUs, images, and data paths you will actually use. The report answers “were these controls designed and, for Type II, did they operate.” It does not answer “is this model safe.”

Security and procurement owners should pull the latest Type II when it exists, plus the bridge letter if the period is stale. This page is a reading method. It is not a catalog of SOC 2 plus ISO 27001 controls, and it does not claim OneSource Cloud holds a SOC 2.

What should you read first, before the pretty opinion page?

If the system description covers “cloud compute” and never mentions accelerators, treat GPU hosting as an adjacent service until the vendor shows an addendum. Do not map your H100 pool onto a CPU VM report because the logo matches.

How do Type I and Type II change the decision?

Type I says controls were designed at a point in time. Type II says they operated over a period, usually several months. For a production GPU estate, Type I is a conversation starter. It is not evidence that last quarter’s access reviews happened.

If the Type II period ended six months ago, ask for a bridge letter and for the next report’s fieldwork dates. GPU providers change firmware, orchestrators, and support vendors quickly. A clean period that predates a new region or a new cluster SKU does not cover that region.

Inclusive versus carve-out method matters. Inclusive means the auditor tested the subservice. Carve-out means you must read that vendor’s report too. Colo plus a GPU software layer is often two reports. Budget the time.

Which GPU-specific questions should you annotate in the margins?

Who can sit at the console of a hypervisor, BMC, or Kubernetes control plane that sees guest GPUs? Look for privileged access, joiner-mover-leaver, and logging of those paths. A SOC 2 that only talks about office laptops is answering the wrong machine.

Where do model weights and customer datasets live, and which backup vendor is in scope? Confidentiality criteria help only if they were in the report and if the storage path you use is in the description. Prompt logs shipped to an observability SaaS may be a silent subservice.

What does availability actually test? Sampled ticket response is not GPU capacity. If your product dies when a rack loses power, look for facility and capacity controls, then still run your own restore test. The attestation is not an SLO.

OneSource Cloud publishes dedicated and private AI infrastructure in U.S. facilities, including Texas / Richardson. Ask any provider, including OneSource, for the current attestation package that matches the service you will buy. Do not infer SOC 2 from a data-center tour. If you also need operations evidence, separate that request from managed AI infrastructure so you do not confuse an ops runbook with an audit report.

What does a clean SOC 2 still fail to prove?

It does not prove FedRAMP authorization, HIPAA adequacy, or that a Business Associate Agreement exists. Those are other instruments. It does not prove model quality, isolation between your own projects, or that MIG versus exclusive GPUs was configured the way you expect.

It does not prove the complementary controls you skipped. If the report says you must encrypt client-side or review user access monthly, and you do neither, the opinion does not travel with you. Write your CUECs into your own control list.

Use the report to open questions for a security questionnaire, then verify on the actual cluster: image pins, secret paths, and who can mount checkpoints. OnePlus Platform, OneSource Cloud's AI orchestration platform, can make some of those mounts and quotas visible. Visibility is not an attestation.

FAQ

Is SOC 2 Type II enough for healthcare GPU hosting?

It is evidence about a service organization’s controls. Healthcare still needs a data-path review, a BAA if PHI is in scope, and your own HIPAA program. A SOC 2 does not replace those. Keep BAA versus DPA questions on their own paper.

Should we accept a SOC 3 instead?

A SOC 3 is a public summary. It is useful for a first screen and weak for GPU-path review. Ask for the SOC 2 under NDA. If the vendor will only share a SOC 3, you cannot test carve-outs or exceptions.

What if the GPU cluster is in a colo the report carves out?

Read the colo operator’s report and the physical access controls that remain on the GPU vendor. Remote hands, cameras, and cage access are where many AI estates actually fail. Two short reports beat one long report that ignores the building.

Does a clean opinion mean we can skip penetration tests?

No. SOC 2 samples controls. It is not a red team of your tenant. Keep independent testing on the shared responsibility list, especially for exposed inference APIs and admin planes.

How often should we re-read the report?

At least when the period rolls, when you add a region or SKU, and when a subservice changes. Tie reread dates to those events, not to a generic annual ritual that misses a mid-year cluster launch. Review healthcare or fintech pages only when those data classes are in the workload, not because the SOC 2 mentioned security.

Summary

Read the system description, criteria, carve-outs, CUECs, and exceptions before you celebrate the opinion. Match them to the GPU service you will use. Type II over a relevant period beats a stale Type I. A clean SOC 2 still leaves FedRAMP, HIPAA, model isolation, and your own user controls unproven.

Ask providers for the package that names the service you are buying, then verify the live cluster. Dedicated U.S. infrastructure can simplify the physical story, but it does not replace the reading work.