Priya Nakamura had read the email from Northfall Bank's third-party risk team three times before she forwarded it to her CEO. Meridian Cloud, the IaaS/PaaS provider where Priya ran infrastructure, had just lost the inside track on a $6.8 million multi-year hosting contract — not because Meridian's platform was insecure, but because Northfall's auditors couldn't get comfortable with what Meridian's existing SOC 2 report didn't say. The report, inherited from a rushed audit two years earlier, covered application-layer access controls reasonably well. It said almost nothing about the physical security of the three data centers Meridian leased rack space in, nothing about how hypervisor isolation was tested, and nothing usable about what Meridian's own upstream providers were responsible for. Northfall's auditors couldn't determine whether Meridian was a "subservice organization" under a carve-out or an inclusive method, because Meridian's report never used the term at all.
Nine months later, Priya's team had rebuilt Meridian's SOC 2 program from the physical layer up — data center environmental controls, hypervisor change management, network segmentation between tenants, a documented Availability criteria program with real capacity forecasting, and a published Complementary User Entity Controls (CUEC) list that let Northfall's auditors slot Meridian cleanly into their own SOC 2 as an inclusive subservice organization. Meridian didn't just win the renewal; the same report closed four new enterprise deals in the following two quarters because prospective customers' own auditors could finally point to it and say "yes, this satisfies our vendor risk requirement." This article is the playbook Priya's team built.
Who This Is For / What You'll Walk Away With
This is written for infrastructure and platform leaders — VPs of Infrastructure, Heads of Data Center Operations, Site Reliability Engineering leads, and the compliance managers who support them — at companies that provide compute, storage, networking, or platform services that other businesses build products on top of. If your customers' engineering teams deploy workloads onto your infrastructure rather than simply logging into your application, this article is about your specific SOC 2 shape. You'll walk away understanding how the shared responsibility model maps to SOC 2 scope, why your report functions differently in your customers' own audits than a typical SaaS vendor's report does, how to structure physical and environmental controls evidence for hyperscale or colocated data centers, and how CUECs and Complementary Subservice Organization Controls (CSOCs) actually get written and used.
Why the Cloud Service Provider's SOC 2 Looks Different
A SaaS company's SOC 2 mostly answers one question: can this vendor be trusted with our data inside their application? A cloud service provider's SOC 2 has to answer a broader and lower-level question: can this vendor be trusted to be the floor that our own controls — and our own SOC 2 reports — stand on? Every layer beneath the point where a customer's own responsibility begins has to be demonstrably controlled, evidenced, and, in a Type II report, tested over an observation period.
That distinction matters because most CSP customers are not consumers or even ordinary B2B buyers — they are companies running their own security frameworks, often including their own SOC 2 programs, and their auditors will need to treat your report as an input to theirs. Get the framing wrong and you create rework for every customer's audit team, every year, indefinitely. Get it right once and it becomes a durable sales asset. If your own product sits purely at the application layer on top of someone else's cloud, the shape of your program looks much more like our companion piece on SOC 2 for SaaS Companies: Service Provider Compliance than what follows here — the two overlap heavily but diverge sharply at the infrastructure boundary.
Dimension | Typical SaaS Company SOC 2 | Cloud Service Provider SOC 2 |
|---|---|---|
Primary scope layer | Application and data layer | Physical, environmental, network, hypervisor, and platform layers |
Physical/environmental controls | Usually inherited via subservice org disclosure | Owned and directly tested |
Typical TSC scope | Security, often + Confidentiality | Security + Availability (frequently + Confidentiality) |
Role in customer audits | Usually a vendor referenced once | Frequently the named subservice organization in dozens/hundreds of customer reports |
CUEC/CSOC publication | Optional, often thin | Expected, detailed, actively used by customer auditors |
Common paired standard | None or ISO 27001 | ISO 27001 + ISO 27017 (cloud-specific controls) |
Multi-tenancy considerations | Rare | Central — isolation, noisy-neighbor, blast radius |
Capacity/uptime evidence | Light | Heavy — utilization trending, failover testing, SLA tracking |
"People assume a cloud provider's SOC 2 is just a bigger version of a SaaS company's. It isn't bigger, it's a different shape entirely. We're not proving we protect our data — we're proving we're a safe foundation for a thousand other companies' data, and their auditors are going to read our report line by line." — Priya Nakamura, VP of Infrastructure, Meridian Cloud
The Shared Responsibility Model, Mapped to SOC 2 Scope
Every cloud provider — whether a hyperscaler, a regional IaaS shop, or a specialized PaaS — operates on some version of the shared responsibility model: the provider secures certain layers, the customer secures others, and the line between them shifts depending on the service model (IaaS, PaaS, or SaaS-on-top-of-your-platform). The mistake I see most often in CSP SOC 2 programs is treating this as marketing language rather than as the literal scoping document for the audit. Your system description — the narrative in Section III of the SOC 2 report — needs to state, layer by layer, exactly where your controls end and the customer's begin, because that boundary is what your auditor tests against and what customer auditors rely on when they build their own control matrices.
Layer | IaaS Responsibility | PaaS Responsibility | Typically Owned By |
|---|---|---|---|
Physical facility (power, cooling, physical access) | Provider | Provider | CSP |
Hardware (servers, storage, network gear) | Provider | Provider | CSP |
Virtualization/hypervisor | Provider | Provider | CSP |
Network controls (perimeter, segmentation) | Provider (perimeter) / Shared (internal) | Provider | CSP + Customer (shared) |
Operating system | Customer | Provider | Varies by model |
Runtime/middleware | Customer | Provider | Varies by model |
Application code | Customer | Customer | Customer |
Identity and access to workloads | Customer | Shared | Customer + CSP |
Data classification and encryption key ownership | Customer (usually) | Shared | Customer, with CSP-managed KMS option |
The practical exercise here — and one I run with every CSP client in week one — is a control-by-control walk of your own architecture against this table, marking each row "sole CSP," "sole customer," or "shared," and then cross-referencing each "shared" row against a specific control ID in your Trust Services Criteria mapping. Ambiguity here is exactly what caused Meridian's original report to fail Northfall's review: three "shared" rows had no control mapped to either party. This mapping exercise is really an extension of the general concept covered in SOC 2 Common Controls: Shared Responsibility in Service Organizations — a CSP simply has many more rows in the "provider owns this layer" column than a typical service organization does.
The CSP as Subservice Organization: Carve-Out vs. Inclusive
This is the single most consequential decision a cloud service provider makes about its SOC 2, and it is made jointly with your auditor and, informally, in negotiation with your largest customers. When a customer undergoes its own SOC 2 examination, and that customer relies on your infrastructure, you are a subservice organization in their report. Their auditor has exactly two ways to handle you: the carve-out method, which excludes your controls from the customer's report and simply discloses that you exist and perform certain functions, or the inclusive method, which pulls your controls — and their test results — directly into the customer's report.
Factor | Carve-Out Method | Inclusive Method |
|---|---|---|
What the customer's report shows | Discloses your existence and function; does not test your controls | Includes your controls and test results in the customer's report body |
What you must provide | Your own independent SOC 2 report + a documented CUEC list | Direct participation: your control owners get interviewed/tested as part of the customer's audit |
Audit burden on you | One SOC 2 cycle per year, reused across all customers | Potential separate testing touchpoints per customer, unless carefully coordinated |
Customer auditor experience | Reviews your SOC 2 independently, maps CUECs | Tests your controls directly — more assurance, more friction |
Typical adoption at CSP scale | Default and strongly preferred at scale | Used selectively for a small number of strategic/regulated accounts |
Report reusability | High — one report serves all carve-out customers | Low — inclusive testing doesn't scale past a handful of relationships |
For any CSP serving more than a handful of enterprise accounts, carve-out has to be the default, and your own SOC 2 report is the mechanism that makes carve-out defensible. A customer's auditor accepting the carve-out method is, in effect, accepting your report as a substitute for direct testing — which means your report needs to be complete enough, current enough, and specific enough that a stranger's auditor can rely on it without a phone call. Inclusive method should be reserved for the rare account — a systemically important bank, a government agency — where the contract or regulator requires direct testing rights, because agreeing to inclusive testing for every customer would mean your control owners spend the year being interviewed by dozens of different audit firms.
"The first question I ask a CSP client's auditor is: are you going to be named, and under which method? If the answer is 'we don't know yet,' that's a scoping failure, not an audit nuance. It has to be decided before fieldwork starts, and it has to match what the CSP tells its own customers in the trust portal." — Lianne Forsythe, CPA, Partner, Forsythe & Cole Assurance
Trust Services Criteria: What's In Scope for a Cloud Provider
Security — the Common Criteria — is mandatory in every SOC 2 and forms the backbone of a CSP's report. But the Trust Services Criteria selection for a cloud provider almost always extends further than for a typical SaaS company, because uptime and capacity are the product, not a feature of the product.
TSC Category | Typical for a CSP? | Why |
|---|---|---|
Security (Common Criteria) | Always in scope | Mandatory baseline; covers access, change, monitoring across all layers |
Almost always in scope | Uptime, capacity, and resilience are core commitments to every customer | |
Confidentiality | Frequently in scope | Multi-tenant data separation, encryption key handling |
Processing Integrity | Occasionally in scope | Relevant if the platform processes/transforms customer data (e.g., managed database or queue services) |
Privacy | Rarely in scope directly | Usually a customer-layer concern unless the CSP directly processes personal data as part of a managed service |
Availability criteria deserve special weight in a CSP context because they are, functionally, the criteria your customers care about most day to day. A customer building a fintech product on your compute layer will forgive a slow support ticket; they will not forgive an unplanned regional outage that takes their own uptime SLA with it. Our companion piece on SOC 2 Availability Criteria: System Uptime and Performance Management goes deep on the criteria themselves; here we'll focus on how they apply specifically at the infrastructure layer.
Physical and Environmental Controls: Owning the Floor
This is the layer that most differentiates a CSP's SOC 2 from a SaaS company's. A SaaS vendor typically discloses that its infrastructure runs on a major cloud platform and inherits physical security through that provider's own SOC 2 (a carve-out reference one level up the stack). A cloud provider that owns or leases raised-floor data center space cannot do that — physical and environmental controls are directly in scope, directly tested, and directly evidenced.
Control Domain | What Auditors Test | Typical Evidence |
|---|---|---|
Perimeter access | Fencing, mantraps, guard staffing, vehicle barriers | Access logs, guard rosters, incident reports |
Facility access provisioning | Badge issuance, approval workflow, termination process | HR/badge system exports, approval tickets |
Data center floor access | Biometric or multi-factor gates to server rows/cages | Badge + biometric logs, visitor escort logs |
Visitor management | Sign-in, escort requirement, ID verification | Visitor logs, escort assignment records |
CCTV coverage | Camera placement, retention period, review process | Camera coverage maps, retention policy, footage retrieval logs |
Power redundancy | UPS, generator, dual power feeds (A/B) | Maintenance logs, load test results, fuel contracts |
Cooling and environmental monitoring | HVAC redundancy, temperature/humidity thresholds | Sensor logs, alert thresholds, maintenance records |
Fire detection/suppression | Detection systems, clean-agent suppression, testing cadence | Inspection certificates, test logs |
Media handling and destruction | Secure disposal of decommissioned drives/media | Destruction certificates, chain-of-custody logs |
Asset inventory | Tracking of physical hardware in and out of the facility | Asset management system exports |
Our companion article, SOC 2 Physical Security: Data Center and Office Protection, covers the general control set in depth. What's specific to a CSP is scale and multi-facility consistency: if you operate across three, ten, or thirty facilities — owned, leased, or colocated — your auditor will sample across facilities, and inconsistent control implementation between sites is one of the most common Type II exceptions I see in CSP engagements. A badge deprovisioning process that works flawlessly at your primary facility and lags by nine days at a colocation site you added last year is a single deficiency that can taint your entire report.
"We had beautiful physical security at our flagship facility and a shrug at the colo site we spun up for disaster recovery capacity. The auditor didn't care that the DR site was 'just for failover' — it held live customer data during a failover test, so it was in scope, and it got tested like everywhere else." — Derek Osei, Data Center Operations Director, Meridian Cloud
Data Center Tiering and Redundancy as Control Evidence
Customers and their auditors increasingly ask CSPs to characterize their facilities using the Uptime Institute's data center tier classifications (Tier I through Tier IV) as shorthand for redundancy posture. SOC 2 itself doesn't require a specific tier — it requires that your Availability and Security controls actually operate as designed — but tier classification is a useful, recognizable way to communicate redundancy commitments inside your system description and in customer due-diligence conversations.
Tier | Redundancy Characteristics | Expected Uptime | Typical CSP Use Case |
|---|---|---|---|
Tier I | Single path for power/cooling, no redundancy | ~99.67% | Not typical for production CSP workloads |
Tier II | Redundant capacity components, single path | ~99.75% | Rare for primary regions; sometimes secondary/backup |
Tier III | Multiple paths, concurrently maintainable | ~99.98% | Common baseline for primary CSP regions |
Tier IV | Fault tolerant, no single point of failure | ~99.99% | Flagship/premium regions, regulated-industry offerings |
Whatever tier language you use externally, the SOC 2 evidence has to substantiate it: generator load tests on a documented cadence, failover drills with recorded results (not just a checkbox that a drill "occurred"), and power feed diagrams that match what's actually wired. I've reviewed more than one system description that claimed dual, independent power feeds where the audit trail showed both feeds terminating at the same upstream substation — a redundancy claim that looked fine on paper and fell apart under a single-point-of-failure analysis. Auditors increasingly ask for that analysis explicitly.
Network Segmentation and the Hypervisor Layer
Below the application and above the physical facility sits the layer that is uniquely a cloud provider's to control: the network fabric and the virtualization layer that turns physical hardware into the compute, storage, and network resources your customers consume. This is where network segmentation stops being a best practice and becomes the mechanism that keeps one customer's workload from ever touching another's.
Control Area | What It Prevents | Typical Implementation |
|---|---|---|
Tenant network isolation | Cross-tenant traffic visibility or injection | Virtual private cloud (VPC) constructs, VLANs, overlay networks (VXLAN) |
Hypervisor isolation | VM escape, cross-VM memory/resource access | Hardened hypervisor builds, regular patching, isolation testing |
Management plane separation | Compromise of customer workloads via admin tooling | Out-of-band management network, jump hosts, MFA on all admin access |
Storage multi-tenancy | Cross-tenant data leakage on shared storage backends | Logical partitioning, encryption per tenant/volume |
API/control-plane access | Unauthorized provisioning or configuration changes | IAM policies scoped to tenant, API rate limiting, audit logging |
East-west traffic control | Lateral movement within the provider's own network | Internal firewalls, microsegmentation, zero trust posture for internal services |
Hypervisor patching deserves its own callout because it's a recurring source of Type II exceptions in CSP audits: patch cadence commitments that look reasonable in policy ("critical patches within 30 days") routinely slip in practice because hypervisor patching requires coordinated maintenance windows across live customer workloads. Auditors will pull the patch management ticket history and compare it against your documented SLA — a policy that says 30 days and a population where the median is 52 days is exactly the kind of deviation that produces a qualified finding on an otherwise clean report. Our related piece on SOC 2 Patch Management: Software Update and Testing Procedures covers the evidence trail auditors expect in more detail.
"We treat hypervisor patch windows the way a hospital treats surgical scheduling — every one gets planned, communicated, and logged, because a slipped patch isn't just a compliance gap, it's a live vulnerability sitting under someone else's production database." — Tomas Reyes, Site Reliability Engineering Lead, Meridian Cloud
Multi-Tenancy Isolation: The Control Customers Actually Ask About
If I had to name the single question that comes up most often in CSP customer due-diligence calls, it's some version of "how do you know my workload can't see or affect another tenant's?" This is a Security-criteria question dressed up as an Availability question — the "noisy neighbor" problem, where one tenant's resource consumption degrades another's performance, sits right at the boundary between the two.
Isolation Layer | Risk Addressed | Evidence Auditors Request |
|---|---|---|
Compute isolation | One tenant's VM/container accessing another's memory or CPU cache | Hypervisor configuration standards, isolation test results |
Storage isolation | Residual data readable by a subsequent tenant on reused storage | Storage wipe/zeroing procedures, encryption-per-volume evidence |
Network isolation | Cross-tenant traffic sniffing or injection | VPC/VLAN configuration audits, penetration test scope covering tenant boundaries |
Resource quota enforcement | Noisy-neighbor performance degradation | Quota/throttling configuration, capacity alerting thresholds |
Blast radius containment | A single tenant incident cascading to others | Incident response runbooks with explicit tenant-scoping steps |
Penetration testing scope is worth calling out specifically here: a CSP's pentest program should explicitly include tenant-boundary testing — an attempt, in a controlled environment, to move from one tenant's allocated resources into another's. Generic external pentests that only probe your public-facing management console miss the control that customers actually care most about. I recommend CSPs commission at least one isolation-focused penetration test annually, separate from the standard external/internal pentest, and retain the scoping document as evidence that isolation was specifically in scope, not incidentally covered.
Availability Criteria in Practice: Capacity, Failover, and SLA Evidence
For most SaaS companies, the Availability criteria are a relatively light lift — some monitoring, a documented incident process, a backup schedule. For a cloud provider, Availability is usually the criteria set with the most control points, because it maps directly to the commitments in every customer contract.
Availability Control | What It Demonstrates | Evidence Cadence |
|---|---|---|
Capacity forecasting | Infrastructure won't run out of headroom under growth | Quarterly capacity reviews with utilization trending |
Automated scaling/failover | Systems respond to load or failure without manual intervention | Failover test logs, autoscaling event logs |
Disaster recovery testing | The organization can recover from a regional/facility loss | DR test results against defined recovery time objective and recovery point objective |
Backup integrity | Backups are recoverable, not just taken | Restore test results, not just backup completion logs |
SLA performance tracking | Commitments to customers are being met | Uptime dashboards, SLA credit/breach logs |
Environmental monitoring | Facility conditions won't cause unplanned downtime | Sensor alert logs, threshold breach records |
Redundant network paths | No single network failure takes down a region | Network topology diagrams, failover test evidence |
The most common gap I find in CSP Availability programs isn't a missing control — it's a control that exists but isn't tested realistically. A disaster recovery runbook that has never been exercised against a live cutover, or a failover test that's run against a synthetic low-traffic window rather than realistic load, produces evidence that satisfies a checkbox but wouldn't survive an actual regional outage. Auditors are increasingly asking not just "does a DR plan exist" but "when was it last executed, what were the results, and what changed afterward." A DR test that surfaces no findings, run every year for three years straight, tends to draw auditor skepticism rather than confidence — it suggests the test isn't rigorous enough to find anything.
"An availability program that's never generated a finding isn't a mature program, it's an untested one. I want to see at least one thing break in a DR drill every year or two — that tells me the test was real." — Lianne Forsythe, CPA, Partner, Forsythe & Cole Assurance
Publishing CUECs and CSOCs: What Customers Need From You
Because a CSP sits underneath so many customers' own control environments, the complementary user entity controls list you publish is one of the most consequential documents your compliance team produces — it's what lets a customer's auditor map their responsibilities cleanly against yours, particularly under the carve-out method. Equally, if you rely on your own upstream vendors (colocation providers, undersea cable operators, hardware suppliers with logistics/security obligations), you need a clear complementary subservice organization controls statement describing what you assume those vendors are doing, since you can't test their controls directly under a carve-out relationship with them.
CUEC Category | Example CUEC for a CSP Customer | Why It Can't Be the CSP's Control |
|---|---|---|
Access management | Customer must manage IAM roles/permissions within their own account | CSP provides the IAM framework; customer controls its own role assignments |
Data classification | Customer must classify and label data appropriately before storage | CSP has no visibility into the business meaning of customer data |
Encryption key management | Customer must manage customer-held encryption keys where offered | CSP can provide KMS infrastructure but not decide customer key policy |
Configuration hardening | Customer must securely configure their own compute instances/OS | CSP secures the hypervisor and host; guest OS is customer-controlled |
Incident notification | Customer must report suspected compromise of their own workloads | CSP cannot see inside customer application logic |
Network configuration | Customer must configure security groups/firewall rules within their VPC | CSP provides the primitives; customer defines the specific rules |
User access reviews | Customer must periodically review its own users' access | CSP has no authority over customer's internal personnel decisions |
Publishing this list isn't a defensive afterthought — it's a sales enablement asset. Every CUEC you document precisely is one less ambiguous email thread during a customer's own audit season. I encourage CSP clients to publish CUECs and a plain-language shared responsibility summary on a public or gated trust portal, version-controlled, so customer audit teams can retrieve the current version without opening a support ticket.
"The CUEC list is the most-downloaded document in our trust portal, by a wide margin. Every fintech and healthtech customer's auditor wants it in the first week of their own fieldwork." — Sandra Kwiatkowski, Compliance Program Manager, Meridian Cloud
How Your Report Actually Gets Used Inside a Customer's Audit
It's worth walking through what literally happens to your SOC 2 report once a customer receives it, because understanding that workflow changes how you write your own. A customer's service organization is preparing its own SOC 2. Its auditor identifies you as a subservice organization providing infrastructure. Under the carve-out method — the default at any scale — your customer's auditor does not test your controls directly. Instead, they perform a vendor review: they read your SOC 2 report (ideally Type II, ideally current within the last twelve months), confirm the TSC categories you cover align with what the customer relies on, check your report for any qualified opinion or noted exceptions relevant to the services the customer consumes, and map your published CUECs against the customer's own control matrix to confirm the customer is actually operating those complementary controls.
Step | What the Customer's Auditor Does | What You Can Do to Make It Frictionless |
|---|---|---|
1. Identify you as a subservice org | Names you in their system description | Confirm your legal entity name and services match what customers expect |
2. Request your current report | Asks the customer (their client) to obtain your SOC 2 | Distribute via a self-serve trust portal with NDA gating, not ad hoc email |
3. Review report currency | Checks the report period isn't stale (ideally within 12 months) | Maintain a consistent annual Type II cadence, publish promptly after issuance |
4. Check TSC alignment | Confirms your Security/Availability scope matches customer reliance | Keep your TSC selection stable year over year; flag scope changes proactively |
5. Review opinion and exceptions | Reads whether any noted exceptions affect the customer's services | Provide a plain-language exceptions summary alongside the full report |
6. Map CUECs | Confirms customer operates the complementary controls you require | Keep the CUEC list current and cross-referenced to specific TSC criteria |
7. Document reliance | Records the review in their own audit workpapers | Offer a short attestation letter confirming report scope on request |
A stale report is the single most common friction point I see. If your Type II observation period ended eleven months before a customer's own fieldwork, and issuance took another two months, you're handing the customer's auditor a report that's aged out of usefulness right when they need it most — forcing an awkward bridge letter request. CSPs with large customer bases should treat report issuance timing as a product deadline, not a compliance nicety: get from period-end to issued report in under 60 days if at all possible, and be ready to issue bridge letters within days, not weeks, when a customer's fiscal calendar doesn't align with yours.
Pairing SOC 2 with ISO 27017 (and ISO 27018)
Because so much of a CSP's control surface is cloud-specific — tenant isolation, virtualization security, cloud-specific incident handling — many cloud providers pair their SOC 2 program with ISO 27017, the international code of practice for information security controls specific to cloud services (an extension of ISO/IEC 27002 aimed at cloud service providers and cloud service customers). Where an ISO 27001 certification demonstrates a certified information security management system exists, ISO 27017 adds cloud-specific control guidance on top of it — shared roles and responsibilities, virtual machine hardening, and cloud administrator access, among others. A related standard, ISO 27018, addresses protection of personally identifiable information in public clouds and is common for CSPs whose customers process regulated personal data.
Framework | What It Adds for a CSP | Relationship to SOC 2 |
|---|---|---|
SOC 2 | Attestation on TSC-based controls, US-market standard, restricted-use report | Independent examination; can run in parallel |
ISO 27017 | Cloud-specific control guidance layered on ISO 27001's ISMS | Complements SOC 2 rather than replacing it; many controls overlap |
ISO 27018 | PII protection specific to public cloud processing | Relevant when CSP directly processes customer personal data |
ISO 27001 (base) | Certifiable information security management system | Frequently run alongside SOC 2 to satisfy both US and international buyers |
Running SOC 2 and an ISO-based program together is common enough among CSPs serving global customer bases that it's worth designing your control environment once and mapping it to both frameworks rather than building parallel programs. Readers evaluating that path should see ISO 27001 vs SOC 2: Which One Do You Need and, for teams running both concurrently, Running ISO 27001 and SOC 2 Together — the crosswalk in ISO 27001, SOC 2 & NIST CSF: Control Mapping is especially useful when you're trying to avoid double-collecting the same evidence for two auditors.
Change Management at Infrastructure Scale
Change management controls look different when a single change can affect thousands of customer workloads simultaneously. A code deploy at a SaaS company might roll out to one production environment; a hypervisor firmware update, a network fabric change, or a storage backend migration at a CSP can touch every tenant on a given host, rack, or region at once. This raises the bar on change testing, staged rollout, and rollback evidence well above what a typical Security-criteria change management control expects.
Change Type | Blast Radius | Typical Control Rigor |
|---|---|---|
Application code (control plane/console) | Provider's own systems only | Standard CI/CD gates, code review, automated testing |
Hypervisor/host firmware | All tenants on affected hosts | Staged rollout by host pool, canary testing, rollback plan required |
Network fabric changes | Potentially an entire availability zone/region | Change advisory board approval, maintenance window, customer notification |
Storage backend changes | All tenants on affected storage cluster | Data integrity verification pre/post, staged migration |
Capacity/scaling changes | Regional performance for all tenants | Load testing, gradual traffic shifting |
Staged rollout — deploying a change to a small percentage of infrastructure first, monitoring, then expanding — is the control auditors most want to see evidenced for infrastructure-layer changes, because it directly demonstrates that a defective change can't take down the whole platform at once. If your change management tooling can't produce a report showing what percentage of hosts/regions a given change had reached at each point in time, that's a gap worth closing before your next audit cycle, not during it.
Incident Response Across a Multi-Tenant Platform
Incident response at a CSP has an added dimension that a typical SaaS company's runbook doesn't need: scoping which tenants are affected, and communicating to potentially hundreds of customers simultaneously, some of whom have their own regulatory notification clocks running the moment you notify them.
IR Phase | CSP-Specific Consideration | Evidence Auditors Expect |
|---|---|---|
Detection | Must distinguish single-tenant vs. platform-wide events | SIEM/monitoring alert taxonomy that tags scope |
Triage | Determine which tenants/regions are affected before broad notification | Incident scoping worksheet or runbook step |
Containment | Isolate affected infrastructure without disrupting unaffected tenants | Documented tenant-aware containment procedures |
Customer notification | Notify affected customers promptly, per contractual/regulatory commitments | Notification templates, timestamps of actual notifications sent |
Status communication | Provide ongoing updates during extended incidents | Status page history, customer communication logs |
Post-incident review | Root cause analysis, tied back to change/config history | Root cause analysis documentation, corrective action tracking |
A subtlety worth flagging: because you're a subservice organization, your incident notification timeline directly feeds your customers' own regulatory clocks — a bank customer subject to a breach notification law may have 72 hours to notify its regulator starting from when it becomes aware, which may be the moment you notify them. CSPs serving regulated industries should build notification SLAs meaningfully tighter than the regulatory minimum their most-regulated customers face, not just tighter than their own comfort level.
Encryption, Key Management, and the Multi-Tenant Data Layer
Encryption at rest and encryption in transit are baseline Security-criteria expectations everywhere, but a CSP has to solve a harder version of the key management problem: whose keys protect data on shared infrastructure, and who can access them.
Key Management Model | Description | Auditor Focus |
|---|---|---|
Provider-managed keys | CSP generates, stores, and rotates keys on customer's behalf | Key rotation cadence, access logging to key material |
Customer-managed keys (CMK) | Customer supplies/controls keys via CSP's KMS | Clear boundary showing CSP cannot access key material improperly |
Bring-your-own-key (BYOK) | Customer imports externally-generated keys | Secure import process, no plaintext key persistence |
Hardware security module-backed | Keys generated/stored in HSMs, never exportable in plaintext | HSM certification, access control to HSM administration |
The control that matters most to sophisticated CSP customers isn't which algorithm you use — AES-256 and TLS 1.2+ are now table stakes and rarely differentiate a report — it's whether your own privileged staff can access customer key material or plaintext data without an auditable, customer-visible trail. Demonstrating least privilege enforcement specifically around key management and customer data access — separate from general employee access reviews — is one of the higher-value additions a CSP can make to its Security-criteria control set, and it directly supports the Confidentiality criteria where in scope.
Visualizing the Stack: Where SOC 2 Scope Sits
The diagram below shows how responsibility, audit scope, and the subservice-organization relationship layer on top of each other for a typical IaaS/PaaS provider — useful as a one-page explainer for sales engineers and customer auditors alike.
flowchart TB
subgraph Customer["Customer-Owned Layer (CUECs apply)"]
A[Application Code & Business Logic]
B[Data Classification & Access Policy]
C[Guest OS / Runtime Configuration]
end
subgraph Shared["Shared Layer"]
D[Identity & Access Management APIs]
E[Network Security Group Rules]
F[Encryption Key Policy]
end
subgraph CSP["CSP-Owned Layer (in SOC 2 scope)"]
G[Hypervisor & Virtualization]
H[Physical Servers, Storage, Network Fabric]
I[Data Center Physical & Environmental Controls]
end
Customer --> Shared --> CSP
CSP -. "CSP's own SOC 2 Type II report" .-> J[Customer's Auditor]
J -. "Carve-out: cited + CUECs mapped / Inclusive: directly tested" .-> K[Customer's Own SOC 2 Report]Common Pitfalls in CSP SOC 2 Programs
Across roughly a decade of working with infrastructure and platform providers on their first and second SOC 2 cycles, the same handful of mistakes recur often enough to warrant a dedicated table.
Pitfall | Why It Happens | Consequence | Fix |
|---|---|---|---|
Undefined carve-out vs. inclusive posture | Never explicitly decided with the auditor | Customer auditors can't rely on the report; ad hoc exceptions | Document the method explicitly in the system description |
Physical controls inconsistent across facilities | New sites added without onboarding to the compliance program | Sampling finds exceptions at newer/smaller sites | Standardized facility onboarding checklist tied to the control matrix |
CUEC list too vague to be usable | Written once, never revisited, copied from a template | Customer auditors can't map it to their own controls | Review and version CUECs at least annually, cross-reference to TSC IDs |
Availability evidence is theoretical, not tested | DR/failover plans exist but aren't exercised under realistic load | Auditor skepticism, potential real-world outage exposure | Run and document real failover/DR tests annually with recorded findings |
Stale report distribution | Report issuance lags observation period end by months | Customers forced into bridge letters repeatedly | Compress the gap between period-end and issuance; automate distribution |
Hypervisor/infrastructure patch SLAs not met in practice | Maintenance windows conflict with live customer workloads | Type II exceptions on patch management testing | Build patch cadence into product roadmap capacity, not an afterthought |
Multi-tenancy isolation untested by pentest | Pentest scope defaults to external perimeter only | Customers' security teams push back in due diligence | Commission a dedicated tenant-isolation penetration test annually |
No plain-language shared responsibility summary | Compliance writes only for auditors, not for customer sales cycles | Slows every enterprise deal's security review | Publish a customer-facing shared responsibility one-pager alongside the report |
Case Study: Meridian Cloud's Carve-Out Rebuild
When Priya's team began the rebuild described at the top of this article, Meridian Cloud was mid-market — roughly 400 enterprise customers, three owned data center facilities, and two colocation sites added through an acquisition eighteen months earlier. The original SOC 2 Type II, issued by a smaller regional firm, ran Security criteria only and never named a carve-out or inclusive method for the subservice organization relationship. Over a nine-month rebuild — new auditor, restructured control matrix, and a physical control standardization project across all five facilities — Meridian added Availability criteria, published its first formal CUEC list (41 individual complementary controls mapped to specific TSC IDs), and documented the carve-out method explicitly in its system description. The resulting Type II report, issued with zero qualified findings after one corrected deficiency during the observation period (a badge deprovisioning lag at the acquired colocation site, remediated and retested), became the reference document cited in 61 separate customer vendor-risk reviews in the following twelve months — including the renewed Northfall Bank contract, now expanded to $9.1 million over three years.
Case Study: BuildForge Cloud's Inclusive-Method Pivot for a Strategic Account
BuildForge Cloud, a PaaS provider specializing in regulated-industry deployments, ran a standard carve-out SOC 2 for four years before its largest customer — a national payments processor — requested inclusive-method testing as a condition of a contract renewal, citing internal audit committee requirements that went beyond typical vendor due diligence. Rather than restructure its entire audit around one account, BuildForge's compliance team negotiated a narrower scope: the payments processor's own auditor would directly test six specific BuildForge controls most relevant to that customer's workload (network isolation, key management, incident notification, and three access-control items), documented as a limited-scope addendum to BuildForge's standard Type II engagement, coordinated to run during the same observation period as the main audit rather than as a separate exercise. The arrangement satisfied the customer's audit committee without obligating BuildForge to repeat direct testing for its other 200+ carve-out customers, and it preserved the reusability that makes carve-out viable at scale. BuildForge's compliance lead described the negotiation as "buying just enough inclusive testing to keep one account, without setting a precedent that would have required us to staff up for direct audits across the whole book."
Case Study: A Regional Outage That Didn't Become a Finding
A CSP client of mine — a specialized GPU-cloud provider I'll call Ridgeline Compute for this discussion — experienced a cooling failure at one of its facilities during a summer heat event, triggering an automated failover that moved affected workloads to a secondary facility within the committed recovery time objective. Because Ridgeline had spent the prior year building out realistic, load-tested failover evidence (rather than synthetic low-traffic tests), the actual incident matched what had already been demonstrated in its most recent DR test almost exactly — the failover completed in 6 minutes against an 8-minute Recovery Time Objective commitment, and no customer data loss occurred against a near-zero Recovery Point Objective. When the incident fell inside Ridgeline's next Type II observation period, the auditor treated it as a positive test of the Availability criteria's operating effectiveness rather than a red flag, because the incident response and post-incident documentation lined up cleanly with the pre-established runbook. Ridgeline's VP of Engineering later noted that the incident became a selling point in due diligence calls — proof, with a real timestamp, that the controls worked under genuine stress rather than only in tabletop exercises.
Cost and Timeline Considerations for a CSP's First SOC 2
Cloud providers building their first SOC 2 program from the infrastructure layer up should expect a heavier lift than a comparable SaaS company, primarily because of the physical/environmental evidence-gathering and multi-facility standardization work.
Cost/Time Driver | SaaS Company (illustrative) | Cloud Service Provider (illustrative) |
|---|---|---|
Readiness assessment | 4–6 weeks | 8–12 weeks (multi-facility scoping) |
Control remediation before audit | 2–4 months | 4–8 months (physical/environmental + hypervisor controls) |
Type I → Type II timeline | 3–6 months observation period | 6–12 months observation period (Availability evidence needs a full cycle) |
Annual audit fieldwork | 1–3 weeks | 3–6 weeks (facility sampling across sites) |
Ongoing compliance headcount | 0.5–1 FTE | 1.5–3 FTE (facilities, network, and platform control owners) |
Physical security capital investment | Minimal (often inherited) | Meaningful (badge systems, CCTV, environmental sensors across sites) |
These figures are illustrative and will vary by facility count, geographic footprint, and how mature your infrastructure automation already is — a CSP that already has strong infrastructure-as-code discipline and centralized fleet management will move faster than one relying on manual, facility-by-facility processes. If you're scoping your own timeline, our SOC 2 Readiness Checklist is built to handle the infrastructure-heavy version of this exercise, not just the application-layer version most tools assume.
Building the Control Matrix: Where to Start
Teams starting from scratch consistently ask the same question: what's the actual first deliverable? For a CSP, I recommend building the control matrix in this order, because each stage depends on decisions made in the one before it.
Stage | Deliverable | Depends On |
|---|---|---|
1 | Shared responsibility boundary document (IaaS/PaaS layer mapping) | Architecture review across all service tiers |
2 | TSC selection (Security + Availability, +Confidentiality if applicable) | Customer commitments and contract language review |
3 | Carve-out vs. inclusive posture decision, documented with auditor | Understanding of largest/most-regulated customer requirements |
4 | Facility inventory and physical control standardization plan | Full list of owned, leased, and colocated sites |
5 | Control matrix mapped to TSC IDs, one row per control | Stages 1–4 complete |
6 | CUEC and CSOC drafts | Control matrix complete; identify what customers/vendors must own |
7 | Evidence collection plan and control owner assignment | Control matrix finalized |
8 | Readiness assessment / gap analysis | Evidence collection plan in place |
Our SOC 2 Trust Services Criteria Mapping Template and SOC 2 Control Matrix / RACI Template are built around exactly this sequence, with rows pre-populated for the physical, network, and hypervisor layers that a pure SaaS template typically omits.
SOC 2 as a Growth Lever, Not Just a Gate
It's tempting to treat all of this — physical control standardization, CUEC documentation, facility-by-facility evidence collection — as pure cost, a tax paid to keep enterprise deals from stalling. I'd push back on that framing after watching enough CSPs go through this process. A well-built SOC 2, scoped correctly for the infrastructure layer, becomes one of the few compliance artifacts that directly shortens sales cycles rather than merely avoiding disqualification. When your CUEC list is precise enough that a customer's auditor can slot you into their own report in an afternoon instead of a month of emails, you've removed friction from every renewal and every net-new enterprise deal that follows. When your Availability evidence includes a real, recent failover test with a specific recovery time, your sales engineers get to cite an actual number instead of a policy statement. Priya's team didn't rebuild Meridian's SOC 2 program to satisfy an auditor — they rebuilt it because the report had become, without anyone quite planning it that way, the most persuasive document in the entire sales process for infrastructure customers who'd been burned by vague vendor assurances before.
Treat your report as a product artifact with its own roadmap: what new capability, once documented and tested, would remove the next recurring objection from customer security reviews? That's the question worth asking every renewal cycle, not just "did we pass."
Ready to see where your infrastructure control matrix has gaps before an auditor finds them? Explore PentesterWorld's SOC 2 Gap Analysis Tool, take the "Are You SOC 2 Ready?" quiz to benchmark your program, or browse the SOC 2 Glossary to accelerate the documentation stage of your own build-out.