SOC 2 for Cloud-Hosted vs On-Premise Infrastructure — What Changes in Your Audit Scope and Evidence

Every SOC 2 kickoff call with a company that hasn't been through one before eventually hits the same question: "does it matter that we're on AWS instead of running our own servers?" The honest answer is yes, considerably — not because one setup is more secure than the other, but because the two paths change what your auditor actually tests, whose evidence you're responsible for producing, and how much of your control environment you can borrow from someone else's report versus building from scratch.

This is worth understanding before scoping begins, not discovering halfway through fieldwork when the evidence requests start looking different than expected.

The Question That Decides Almost Everything: Who Owns the Subservice Organization

The single biggest structural fork between cloud-hosted and on-premise SOC 2 audits comes down to one concept: the subservice organization, and whether it's carved out of your report or included in it.

If your infrastructure runs on AWS, Google Cloud, or Azure, that provider is a subservice organization under AICPA's framework — a third party whose services form part of the system you're being audited on. Because the major cloud providers already maintain their own current SOC 2 Type 2 reports, the near-universal approach is the carve-out method: your system description identifies the provider, describes what they handle, and your auditor doesn't independently test their controls at all. You point to their report; they point to theirs. This is genuinely the standard, low-friction path, and it's why the majority of SaaS companies pursuing SOC 2 certification never have an auditor asking to see a cloud provider's data center in person.

On-premise infrastructure removes that shortcut. If you own and operate your own physical servers in your own facility, there's no subservice organization to carve out — your auditor tests your physical security, environmental controls, and infrastructure management directly, because you are the entity responsible for all of it. Colocation sits in between: if your hardware lives in a third-party data center you don't own, that colo provider becomes its own subservice organization, usually carved out the same way a cloud provider would be, provided they maintain their own current report.

Physical and Environmental Evidence Looks Completely Different

This is where the practical evidence burden diverges most visibly. For a cloud-hosted company under the carve-out method, physical and environmental security evidence largely becomes a vendor management exercise: obtaining the cloud provider's SOC 2 report annually, reviewing it for relevant exceptions, and documenting that review as your own control — generally mapped to Complementary Subservice Organization Controls under criteria like CC9.2 for vendor risk and CC3.2 for risk identification. Your auditor wants to see that you're doing this monitoring consistently, not that you personally inspected a data center floor.

A genuinely on-premise company doesn't get that shortcut. Badge access logs, visitor sign-in records, camera footage retention, fire suppression testing, and power redundancy documentation all become direct evidence your own auditor reviews firsthand, because there's no third-party report to lean on. This is often the single biggest surprise for a company moving from a cloud-first mental model into an on-premise or hybrid SOC 2 audit for the first time — physical security stops being something you can reference and becomes something you have to prove.

Change Management and Availability Controls Shift Responsibility, Not Effort

It's tempting to assume cloud infrastructure simply means less evidence overall, but that's not quite right — it shifts where the evidence burden sits rather than eliminating it. A cloud-hosted environment typically benefits from provider-managed patching, built-in redundancy, and autoscaling that reduces some of the manual evidence a company would otherwise need to generate around capacity planning and failover testing. But the shared responsibility model means your organization is still fully accountable for correctly configuring everything above the provider's boundary — access policies, encryption settings, logging configuration — and auditors specifically probe whether that boundary is actually understood internally, not just assumed.

On-premise environments carry the fuller weight of this evidence directly: capacity planning documentation, disaster recovery test results, backup restoration evidence, and failover exercises all need to be internally generated and internally owned, since there's no provider absorbing part of that responsibility. This generally means a heavier internal evidence load for availability-related criteria specifically, compared to a cloud-hosted environment leaning on a provider's own resilience infrastructure.

Scope Creep Shows Up Differently in Each Environment

Cloud environments have a specific failure mode that on-premise infrastructure structurally avoids: sprawl. Forgotten storage buckets, orphaned virtual machines, and abandoned test environments accumulate quietly in cloud accounts and can expand a SOC 2 audit's scope in ways nobody anticipated at kickoff, simply because they exist and technically fall within the system boundary. Cloud asset discovery and tagging discipline isn't optional hygiene here — it's what keeps audit scope matching what the company actually intended to include.

On-premise infrastructure tends to have a more naturally bounded network topology — there's a physical rack, a defined network segment, a smaller surface that doesn't silently expand the way a cloud account can. The tradeoff is that on-premise environments often lack the kind of automated discovery and centralized logging that cloud platforms provide natively, so identifying configuration drift or an undocumented device on the network tends to depend more heavily on manual processes rather than platform-native tooling.

Access Control Evidence: Native Logging vs. Manually Assembled Evidence

Cloud platforms generally make access control evidence easier to produce, not because access control itself is simpler, but because identity and access logs, SSO enforcement records, and MFA compliance reporting are usually available natively through the provider's own console or API — an auditor can review a clean, exportable audit trail rather than reconstructing one manually.

On-premise environments frequently rely on firewall configuration reviews, manually maintained network segmentation diagrams, and physical rack access logs that don't come pre-packaged the way cloud IAM logging does. None of this is a weaker control by definition — a well-run on-premise environment can absolutely meet the same Trust Services Criteria — but the evidence has to be actively assembled and maintained rather than pulled from a platform that was already logging everything by default.

The Ongoing Obligation Cloud-Hosted Companies Often Underestimate

Choosing the carve-out method for a cloud provider doesn't mean the relationship disappears from your control environment — it becomes an ongoing vendor management obligation. Auditors expect to see that a company is actually collecting its cloud provider's current SOC 2 report annually, reviewing it for exceptions relevant to their own service commitments, and documenting that review as a functioning control, not a one-time checkbox from the initial audit setup. Companies that treat this as "we're on AWS, so we're covered" without an actual review process tend to get flagged for exactly this gap.

Hybrid Infrastructure Doesn't Get to Pick One Path

Most companies aren't purely cloud or purely on-premise in practice — a SaaS platform hosted on AWS with an on-premise legacy system still handling certain workloads, or a colocation setup layered with cloud backup, is a genuinely common real-world configuration. This doesn't simplify scoping; it means the system description needs to draw a precise boundary around which components sit under which evidence model, and the audit needs to account for both a carve-out relationship for the cloud portion and direct testing for whatever remains on-premise. Getting this boundary vague rather than precise is one of the more common causes of scope disputes mid-audit.

Where Accorp Fits In

Accorp Partners works with companies across all three infrastructure models — pure cloud, on-premise, and hybrid — and the first thing we map before scoping a SOC 2 audit is exactly this boundary: which controls can legitimately be carved out and referenced against a provider's own report, and which ones your organization needs to own and evidence directly. Getting this mapping right at the start is what keeps a SOC 2 Type 2 audit from turning into a scramble for evidence nobody realized they'd need to produce themselves.

Frequently Asked Questions

1. Does cloud-hosted infrastructure automatically make SOC 2 compliance easier?
Not automatically. It shifts where evidence responsibility sits — reducing physical and environmental evidence burden through the carve-out method, but introducing its own risks like account sprawl and shared-responsibility misconfiguration that on-premise environments don't face in the same way.

2. What is the carve-out method in a SOC 2 audit?
It's the approach where a subservice organization's controls — such as a cloud provider's physical security — are excluded from direct testing, with the auditor instead relying on the provider's own current SOC 2 report.

3. Do on-premise companies need a subservice organization carve-out?
Only if they use colocation. A company that owns and operates its own facility has no subservice organization for that infrastructure and must have physical and environmental controls tested directly by its auditor.

4. Is a SOC 2 report less credible if a company relies heavily on carved-out cloud provider controls?
No, provided the company maintains an active vendor monitoring process — reviewing the provider's report annually and documenting it as a functioning control, which auditors specifically look for under vendor risk management criteria.