SOC 2 Compliance Checklist: What Changes Between On-Premise Servers and Cloud Infrastructure

If you ask three different consultants what SOC 2 compliance requires, you'll get three different answers depending on where your infrastructure sits. That's not because the Trust Services Criteria change based on the hosting environment — they don't. What changes is how you satisfy them, who owns which piece of evidence, and how much manual work your team is signing up for.

Companies running on-premises data centres often assume SOC 2 will be harder because they don't get a neat compliance dashboard from AWS or Azure. Companies in the cloud often assume they're halfway done because their provider is already SOC 2 certified. Both assumptions cause problems during the actual audit. Here's what each environment genuinely requires.

The One Thing That Doesn't Change: The Trust Services Criteria

Before splitting into on-prem and cloud paths, it's worth being clear on what stays constant. Every SOC 2 report — regardless of infrastructure — is built around the five Trust Services Criteria: Security (mandatory), Availability, Processing Integrity, Confidentiality, and Privacy. Your auditor is testing whether your controls around these categories are designed appropriately and, for a Type II report, whether they operated effectively over the review period (typically 3-12 months).

Hosting location doesn't remove any of these obligations. It only changes the mechanics of proving them.

Part 1: SOC 2 Compliance for On-Premise Infrastructure

You Own the Entire Physical Security Story

When your servers sit in a data centre or server room you control, physical security controls are entirely yours to build and evidence. Auditors will expect to see:

• Badge access logs or biometric entry systems for the server room, with a documented list of who has access and why

• CCTV coverage of entry points, with retention policies that match your audit window

• Environmental controls — fire suppression, temperature/humidity monitoring, UPS and generator backup — with maintenance records

• Visitor logs for anyone entering the facility who isn't on the standard access list

This is the part that catches on-prem teams off guard most often. It's not enough to have a locked server room; you need six to twelve months of access logs, incident tickets, and maintenance records sitting ready when the auditor asks.

Patch Management and Change Control Sit Entirely With You

On cloud infrastructure, the provider handles hypervisor-level patching and a chunk of the underlying stack. On-prem, patching the OS, firmware, network devices, and applications is entirely your responsibility — and so is proving it happened on schedule.

Build a patch management policy that specifies cadence (critical patches within X days, routine patches on a monthly cycle), and keep a ticketing trail showing patches were tested, approved, and deployed. Auditors will sample specific patches and ask you to walk through the approval chain.

Network Segmentation and Perimeter Defense

Without a cloud provider's virtual private cloud tooling doing the heavy lifting, you're responsible for firewalls, VLANs, intrusion detection/prevention systems, and demonstrating that production, development, and corporate networks are properly segmented. Auditors typically want to see network diagrams, firewall rule reviews (usually quarterly), and evidence that rule changes go through a change management process rather than being made ad hoc by whoever's on call.

Backup, Disaster Recovery, and Business Continuity

On-prem environments need a genuinely tested backup and DR strategy — not just a backup job that runs nightly, but evidence of periodic restore tests and a documented recovery time objective (RTO) and recovery point objective (RPO). If your DR site is a second physical location, that location needs its own security controls documented too. This is one area where on-prem compliance work tends to run longer than teams expect, because "we have backups" and "we have a tested, working recovery process" are very different audit answers.

Asset Inventory and Hardware Lifecycle

Every server, switch, and storage device needs to be in a maintained asset inventory, with a documented decommissioning process — including secure data wiping or physical destruction of drives before hardware leaves your custody. Auditors will ask for evidence that a decommissioned server didn't walk out the door with unencrypted customer data still on the disk.

Staffing Reality Check

On-prem SOC 2 programs are genuinely more labor-intensive. You need people (internal or outsourced) capable of patch management, network administration, and physical security oversight, in addition to the governance layer — risk assessments, vendor management, access reviews — that every SOC 2 program needs regardless of hosting model. Budget for this before you budget for the audit fee itself.

Part 2: SOC 2 Compliance for Cloud Infrastructure

Understand the Shared Responsibility Model — Precisely

The most common cloud mistake is treating "AWS is SOC 2 compliant" as equivalent to "we are SOC 2 compliant." It isn't. Cloud providers issue their own SOC 2 reports covering the infrastructure layer they control — physical data centers, hypervisor security, network backbone. Everything above that line — your application configuration, IAM policies, data encryption choices, logging setup, and how you configure the services you consume — remains squarely your responsibility.

Your auditor will still test controls at your layer. Get your cloud provider's own SOC 2 Type II report early in the process; you'll need it as a subservice organization reference in your own report, either under the "carve-out method" (excluding their controls and describing complementary user-entity controls you rely on) or the "inclusive method." Most companies use the carve-out method because it's simpler.

Identity and Access Management Is Your Biggest Control Surface

Where on-prem compliance leans heavily on physical access, cloud compliance leans heavily on IAM. Expect auditors to focus on:

• Least-privilege role assignment across cloud accounts, with periodic (usually quarterly) access reviews

• Multi-factor authentication enforced on all accounts with elevated privileges, ideally on all accounts

• Logging and alerting on privileged actions — root account usage, IAM policy changes, security group modifications

• A documented offboarding process that revokes cloud access within a defined window of an employee's exit

Poorly governed IAM is the single most common finding in cloud SOC 2 audits, mainly because permissions creep quietly over time as teams grant broad access to move faster.

Configuration Management and Infrastructure-as-Code

Cloud environments change faster than on-prem ones, which is exactly why configuration drift becomes a real audit risk. If you're using infrastructure-as-code (Terraform, CloudFormation, or similar), that's a genuine advantage — it gives you a version-controlled, reviewable trail of every infrastructure change, which auditors generally like. If you're still making changes through the console manually, you'll need a separate change-approval workflow and ticketing evidence to compensate.

Logging, Monitoring, and Cloud-Native Security Tooling

Auditors will expect centralized logging (CloudTrail, Azure Monitor, or equivalent) with retention aligned to your audit period, along with active monitoring for anomalous activity — unusual API calls, geographic login anomalies, spikes in data egress. Native tools like GuardDuty, Security Hub, or Microsoft Defender for Cloud are commonly used to satisfy this, but the control isn't "we have the tool turned on" — it's "we review alerts and have a documented response process."

Encryption, Key Management, and Data Residency

Cloud platforms make encryption at rest and in transit easy to enable, but SOC 2 auditors want to see the decision documented, not assumed. Confirm and evidence: encryption is enabled on all storage services holding sensitive data, key management is handled through a proper KMS with defined rotation policies, and — if you operate under data residency obligations in specific jurisdictions — that your region configuration actually matches your data residency commitments to customers.

Vendor Risk Extends Further Than You Think

In a cloud model, your vendor risk management program needs to cover not just your primary cloud provider but any third-party SaaS tools that touch in-scope data — your CI/CD pipeline, monitoring tools, customer support platform, and so on. Auditors increasingly ask for a documented vendor inventory with risk tiering and evidence that you've reviewed each vendor's own security posture (their SOC 2 report, if they have one).

Where Hybrid Environments Complicate Things

Most mid-sized companies aren't purely one or the other — they run core systems on-prem while using cloud services for specific workloads, or they're mid-migration. In hybrid setups, the audit scope has to draw a clear boundary around exactly which systems are in scope, and you'll effectively need to satisfy both the physical-control checklist for on-prem components and the shared-responsibility/IAM checklist for cloud components. This is where scoping conversations with your auditor early — before evidence collection starts — save the most time later.

Building Your Compliance Roadmap

Regardless of infrastructure, a workable SOC 2 preparation sequence looks roughly like this: run a readiness assessment against the relevant Trust Services Criteria, remediate control gaps, formalize policies that are currently informal practice, collect evidence over the review period (this is the part that differs most by environment), and then bring in a licensed CPA firm for the actual Type I or Type II audit — SOC 2 reports can only be issued by licensed CPAs, not by consultants or automated compliance platforms alone, even when those platforms are genuinely useful for evidence collection.

The infrastructure decision shapes your workload, your evidence collection process, and where your team's compliance effort actually goes. It doesn't change what "compliant" means — it changes what it takes to get there.