SOC 2 for Cloud Infrastructure Providers

If your infrastructure customers keep asking for a SOC 2 report that can survive their own downstream audits, you are not alone — this is the most common challenge we see with cloud infrastructure and hosting companies. Here is how we help infrastructure providers build SOC 2 programs that hold up under the most intense scrutiny in the market.

Cloud infrastructure providers, hosting companies, IaaS/PaaS platforms, and managed service providers face the most scrutinized SOC 2 reports in the market. Your customers — SaaS companies, enterprises, and regulated organizations — depend on your SOC 2 report to support their own compliance programs. When a SaaS company's auditor evaluates their control environment, your SOC 2 report serves as evidence that the underlying infrastructure controls are sound. This downstream dependency means infrastructure provider SOC 2 reports receive more intense review than any other vendor category, and weaknesses in your report directly impact your customers' audit outcomes.

This guide covers SOC 2 compliance specifically for cloud infrastructure and hosting companies, addressing the subservice organization model, the inclusive versus carve-out method, complementary user entity controls (CUECs), Trust Service Criteria selection for infrastructure providers, availability and uptime SLA documentation, and how to build a SOC 2 report that withstands the intense scrutiny of downstream auditors and enterprise security teams.

The Subservice Organization Model

When your customers undergo their own SOC 2 audits, they must address how they rely on third-party infrastructure providers. You are a "subservice organization" in SOC 2 terminology — an organization that provides services to a service organization (your customer), which in turn provides services to its own customers (end users).

Why This Matters

Your customers' SOC 2 auditors must evaluate whether infrastructure-level controls are adequate. They do this by reviewing your SOC 2 report. If your report has significant exceptions, covers an insufficient scope, or uses a limited trust criteria set, your customers face audit complications — potentially exceptions in their own reports.

This downstream accountability creates strong market pressure. In our experience working with infrastructure providers, these dynamics are non-negotiable:

• Customers will not use infrastructure providers without a current SOC 2 Type II report
• Enterprise customers require specific Trust Service Criteria in your report (typically Security, Availability, and Processing Integrity)
• Customer auditors may contact you directly to clarify report findings
• Switching infrastructure providers due to SOC 2 inadequacy is costly, so buyers evaluate reports carefully before committing

Inclusive vs Carve-Out Method

Your customers choose one of two methods to address your services in their SOC 2 report:

Method	How It Works	Impact on You
Inclusive method	Your customer's auditor evaluates your controls directly as part of their audit	Your controls are tested in detail; high scrutiny on your control environment
Carve-out method	Your customer's report states that they rely on your services and references your SOC 2 report	Your SOC 2 report must be comprehensive enough to satisfy downstream auditor review

The carve-out method is far more common because the inclusive method requires your customer's auditor to have direct access to your systems and evidence. Under the carve-out method, your SOC 2 report becomes the primary evidence of your infrastructure control effectiveness — making report quality critical. We recommend that every infrastructure provider treat their SOC 2 report as a customer-facing product that must meet an exceptionally high quality bar.

Trust Service Criteria for Infrastructure Providers

Infrastructure providers should include more Trust Service Criteria than the typical SaaS company because downstream customers depend on your service characteristics beyond basic security. We advise our infrastructure clients to think about criteria selection from the perspective of their customers' auditors — not just their own compliance requirements.

Recommended Criteria

Criterion	Recommendation	Reasoning
Security (Common Criteria)	Required	Mandatory for all SOC 2 audits
Availability	Strongly recommended	Infrastructure uptime directly affects customer service delivery; most customers expect this
Processing Integrity	Recommended	Validates that infrastructure processing (compute, storage, networking) operates correctly
Confidentiality	Recommended	Validates protection of customer data across shared infrastructure
Privacy	Situational	Required only if you process end-user personal data (uncommon for pure infrastructure)

Why Availability Is Essential

For infrastructure providers, Availability is not optional in practice — even though it is technically optional in the SOC 2 framework. What we tell clients is: if you provide infrastructure, your customers' services live or die on your uptime. Enterprise buyers purchasing infrastructure for mission-critical applications will not consider providers whose SOC 2 reports lack Availability criteria. Including Availability requires:

• Documented uptime commitments and SLA targets
• Capacity monitoring and planning procedures
• Redundancy and failover mechanisms
• Backup and recovery procedures with documented RTO and RPO
• Incident communication procedures for availability events
• Historical uptime data and incident response records

Why Processing Integrity Matters

Infrastructure providers that handle compute, storage, or networking must ensure these services operate correctly. Processing Integrity validates that your infrastructure does not introduce errors, data corruption, or processing failures. In our experience, this criterion is increasingly expected by enterprise buyers. For infrastructure providers, this means:

• Storage services maintain data integrity (no silent corruption)
• Compute services execute workloads as specified
• Networking services route traffic correctly and securely
• Database services maintain transactional integrity
• API services process requests accurately

Complementary User Entity Controls (CUECs)

CUECs are controls that your customers must implement on their end for the overall control environment to function as intended. For infrastructure providers, CUECs are particularly important because you provide the platform but your customers configure and operate their applications on top of it. We recommend treating CUECs as one of the most strategically important sections of your SOC 2 report.

Common CUECs for Infrastructure Providers

CUEC	What It Requires of Your Customer	Why It Is Necessary
Access management	Customers must manage their own user access to resources on your platform	You provide the access control tools; customers must use them appropriately
Encryption configuration	Customers must enable encryption for their data stored on your platform	You offer encryption capabilities; customers must activate them
Network security configuration	Customers must configure security groups, firewall rules, and network ACLs	You provide networking controls; customers must configure them for their workloads
Backup configuration	Customers must configure backup schedules and test recovery procedures for their data	You provide backup tools; customers must set them up
Monitoring configuration	Customers must set up monitoring and alerting for their applications and resources	You provide monitoring capabilities; customers must implement them
Patch management	Customers must patch their own operating systems and application software	You manage infrastructure; customers manage their software stack
Security incident reporting	Customers must report suspected security incidents to your security team	Effective incident response requires customer cooperation

Documenting CUECs Effectively

CUECs must be documented clearly in your SOC 2 report's system description. In our experience, ambiguous CUECs are one of the most common weaknesses we see in infrastructure provider reports — they create problems for your customers because their auditors cannot determine what their responsibilities are. For each CUEC, we recommend:

• State the specific control the customer must implement
• Explain why the control is necessary (what risk it addresses)
• Describe how the customer can verify they have implemented it
• Reference any platform tools or documentation that support implementation

Well-documented CUECs demonstrate compliance maturity and make your report more valuable to downstream auditors.

---

---

Infrastructure-Specific Controls

Beyond standard SOC 2 controls, infrastructure providers must address controls specific to their service delivery model. We walk our infrastructure clients through each of these areas during scoping to ensure nothing is missed.

Multi-Tenancy Controls

Control Area	What Auditors Evaluate
Tenant isolation	Logical separation between customer environments ensuring one tenant cannot access another's data or resources
Resource allocation	Fair resource distribution preventing one tenant from degrading another's performance
Data segregation	Customer data stored and processed in isolated contexts with no cross-tenant data leakage
Configuration isolation	Customer configurations cannot affect other tenants' environments
Noisy neighbor mitigation	Controls preventing resource contention between tenants

Physical and Environmental Controls

Infrastructure providers with data center operations face additional physical security requirements:

• Physical access controls (biometric, badge, multi-factor physical authentication)
• Environmental monitoring (temperature, humidity, water detection)
• Power redundancy (UPS, generator, dual power feeds)
• Fire suppression systems
• Visitor management procedures
• Equipment disposal and media destruction

For providers using hyperscale cloud (AWS, Azure, GCP) as their underlying infrastructure, we recommend referencing the cloud provider's own SOC 2 report for physical and environmental controls and focusing your report on the controls you operate on top of that infrastructure.

Change Management for Infrastructure

Infrastructure change management is more complex than application change management because changes can affect all customers simultaneously. What we tell clients is that this is one of the areas where infrastructure SOC 2 reports diverge most significantly from application-level reports:

• Infrastructure changes must include impact assessment across the customer base
• Maintenance windows must be communicated to affected customers in advance
• Rollback procedures must be tested and documented
• Emergency change procedures must balance speed with safety
• Configuration management databases (CMDBs) must accurately reflect infrastructure state

Capacity Management

Control	Evidence
Capacity monitoring	Dashboards and reports showing resource utilization across infrastructure
Capacity planning	Documented capacity planning process with growth projections
Auto-scaling configuration	Architecture documentation showing auto-scaling capabilities and thresholds
Threshold alerting	Alert configurations that trigger before capacity limits are reached

Building a Report That Withstands Scrutiny

Report Quality Indicators

Downstream auditors and enterprise security teams look for specific indicators of a strong infrastructure provider SOC 2 report. Based on what we see reviewing reports across the industry, these are the markers of a credible infrastructure SOC 2:

• Complete Trust Service Criteria coverage: Security, Availability, and Processing Integrity at minimum
• Twelve-month observation period: Demonstrates sustained operational control effectiveness
• Detailed system description: Clearly documents service architecture, boundaries, tenant isolation, and data flows
• Comprehensive CUECs: Well-defined customer responsibilities that demonstrate mature shared responsibility understanding
• Minimal exceptions: Zero exceptions is ideal; any exceptions must include clear remediation plans
• Recognized CPA firm: Reports from established audit firms carry more credibility

Common Report Weaknesses

Weakness	Impact on Customers	How to Avoid
Missing Availability criterion	Customers cannot reference your report for availability-related controls	Include Availability from your first Type II audit
Vague CUECs	Customer auditors cannot determine responsibility boundaries	Write specific, actionable CUECs with implementation guidance
Short observation period (3 months)	Downstream auditors may question control sustainability	Use six-month minimum; twelve-month preferred
Significant exceptions in access management	Raises concerns about multi-tenant isolation	Prioritize access management controls and quarterly access reviews
Outdated report (more than 12 months old)	Customers cannot use an expired report for their current audit	Maintain annual audit cycle without gaps

Key Takeaways

• In our experience, infrastructure provider SOC 2 reports face the most intense downstream scrutiny because customers depend on them for their own compliance — we help clients prepare for this level of review from day one
• We strongly recommend including Security, Availability, and Processing Integrity at minimum — enterprise infrastructure buyers expect all three, and omitting Availability or Processing Integrity limits your report's usefulness to downstream auditors
• What we see most often is that the carve-out method drives report quality: your SOC 2 report becomes the primary evidence of your infrastructure control effectiveness for downstream auditors, and we advise treating it as a customer-facing product
• We always tell clients that CUECs must be specific and actionable — they define the shared responsibility boundary between you and your customers, and vague CUECs are one of the most common weaknesses we see in infrastructure reports
• In our experience, multi-tenancy controls (tenant isolation, data segregation, resource allocation) are critical infrastructure-specific requirements that auditors evaluate closely
• We recommend that infrastructure change management explicitly address the broader customer impact of platform-level changes — this is where infrastructure SOC 2 diverges most from application-level compliance
• We advise twelve-month observation periods and recognized CPA firms to strengthen report credibility with the downstream auditors who will review your report most carefully
• For providers with data center operations, physical security controls are required; for cloud-hosted providers, we recommend clearly referencing your hyperscale provider's SOC 2 report and focusing your report on what you operate

Frequently Asked Questions

Why do infrastructure provider SOC 2 reports get scrutinized more than other vendors?

What we tell clients is: you sit at the bottom of the trust stack, and that makes your SOC 2 report the foundation that everyone above you depends on. When a SaaS company undergoes a SOC 2 audit, their auditor must verify that the underlying infrastructure controls are sound. Your SOC 2 report is the primary evidence for that verification. If your report is weak, every customer that relies on your infrastructure faces audit complications. Based on what we see, this downstream dependency creates a higher bar for infrastructure provider reports compared to application-level SaaS vendors — and it is the single most important reason to invest in report quality.

Do we need all five Trust Service Criteria?

In our experience, Security is mandatory. We strongly recommend Availability and Processing Integrity for infrastructure providers because your customers depend on your uptime and processing accuracy. We also recommend Confidentiality for providers that handle customer data in multi-tenant environments. Privacy is only necessary if you process end-user personal data directly, which is uncommon for pure infrastructure providers. What we typically see is that most infrastructure provider reports include three to four criteria, and the ones that include fewer than three face pushback from enterprise buyers.

How should we handle the shared responsibility model in our SOC 2 report?

What we advise clients is to document the shared responsibility model through clearly defined CUECs in your system description. For each service capability, specify what you are responsible for (infrastructure-level controls) and what the customer is responsible for (application-level configuration and operations). In our experience, the best infrastructure reports reference the platform's shared responsibility documentation and ensure CUECs are specific enough that customer auditors can verify implementation without ambiguity.

What is the difference between inclusive and carve-out method for our customers?

Based on what we see with our infrastructure clients, the carve-out method is used in the vast majority of cases. Under the carve-out method, your customer's SOC 2 report states that they rely on your services and references your SOC 2 report — your controls are not tested directly by their auditor. Under the inclusive method, their auditor evaluates your controls directly as part of their audit scope. Most customers use carve-out because inclusive requires direct access to your systems. What we tell clients is that the carve-out method makes the quality and completeness of your SOC 2 report essential — it is the only evidence their auditor reviews, so it needs to stand on its own.

How often do infrastructure providers need to renew their SOC 2 report?

We recommend maintaining an annual audit cycle with no gaps between report periods. Your customers' auditors need a current (less than twelve months old) SOC 2 report for each audit cycle. In our experience, if your report expires without renewal, customers may receive exceptions in their own audits for relying on a provider without current attestation. What we tell clients is that a lapsed SOC 2 report is not just a compliance gap — it is a customer retention risk, because your customers cannot use an expired report for their current audit.