SOC 2 for cloud providers

SOC 2 for cloud providers is an independent report that proves your hosting infrastructure is secure, available and confidential. An accountant tests your security against the AICPA Trust Services Criteria . Customers who run on your servers ask for this report before they do business with you.

You host infrastructure for others. Customers run their applications on your servers. SOC 2 is not only useful, it is the industry standard. Hyperscalers (AWS, Azure, GCP) have it. Managed service providers have it. You should have it too.

Cloud providers are often audited against several Trust Services Criteria at once. See also the commonly used controls for concrete examples.

SOC 2 for cloud providers in brief

Why SOC 2 is essential for cloud and hosting

Customer requirement: Every customer that runs on your infrastructure must be compliant themselves (GDPR, ISO 27001, SOC 2). They ask for your SOC 2 as part of their vendor risk management. Without SOC 2, they cannot accept you as a supplier.

Shared responsibility model: You are responsible for the security of the cloud (physical, network, hypervisor). The customer is responsible for security in the cloud (their apps, their data). Your SOC 2 shows that your part is in order.

Competition: AWS, Azure and GCP have SOC 2. Smaller cloud providers do too. Without SOC 2, you cannot compete. “Why would we choose you over AWS?” Your answer must at least be: “We have the same compliance.”

Cloud-specific SOC 2 controls

1. Physical security (critical for your own data centre)

If you own your hardware, physical security is a large part of the work.

Controls:

• Site security: Fences, gates, guards
• Access control: Badge systems, biometrics (fingerprint, iris)
• Visitor management: Logbook, mandatory escort, temporary badges
• CCTV: 24/7 cameras, recordings kept for at least 90 days
• Climate and power: Fire suppression, cooling, backup power (UPS, generators)
• Asset tracking: Server inventory, procedures for decommissioning

What the auditor asks:

• “Show me the data centre access logs. Who entered in the last 6 months?”
• “How do you manage visitor access?”
• “What happens when an unauthorised person gets in?”
• “Show a sample of camera footage.”

If you use colocation: You rent space in someone else’s data centre (Equinix, Digital Realty). Their physical security becomes your control. You must:

• Have the supplier’s SOC 2 report
• Have your own access controls inside your cage or rack
• Keep visitor logs
• Be able to show the auditor your supplier’s SOC 2 report

If you are fully in the cloud (AWS/Azure/GCP): Physical security is the responsibility of AWS, Azure or GCP. The auditor accepts their SOC 2 as evidence. Your scope is logical access, not physical access.

2. Hypervisor and virtualisation security

You run customers in VMs or containers. How do you isolate them?

Controls:

• Hypervisor hardening: ESXi, KVM, Hyper-V kept up to date and patched
• VM isolation: The VM of customer A cannot reach that of customer B
• Resource allocation: CPU and memory limits per tenant (prevents a noisy neighbour)
• Network segmentation: VLANs and VPCs per customer
• Escape prevention: Vulnerabilities in the hypervisor are patched quickly

What the auditor asks:

• “Explain your virtualisation architecture.”
• “How do you prevent a VM escape?”
• “Show me the network isolation. Can VM A reach the network of VM B?”
• “Suppose there is a vulnerability in the hypervisor. Within what timeframe do you patch it?”

Evidence:

• Architecture diagram (hypervisor, network)
• Patch management logs (hypervisor updates)
• Network segmentation configuration
• Penetration test: an attempted VM escape (it must fail)

Best practice: Use hardware isolation where possible (Intel VT-x, AMD-V). Use namespaces and cgroups for containers. Run security reviews of your hypervisor configuration regularly.

3. Network security and DDoS protection

Your network is publicly reachable. DDoS attacks are a reality.

Controls:

• DDoS mitigation: Scrubbing centres, rate limiting, null routing
• Firewalls: Stateful firewalls, deny everything by default
• IDS/IPS: Detection and prevention of intrusions
• Traffic monitoring: NetFlow, anomaly detection
• Bandwidth management: QoS, traffic shaping
• Peering: Multiple upstream providers (redundancy)

What the auditor asks:

• “What is your DDoS mitigation strategy?”
• “Show me a recent DDoS attack and how you handled it.”
• “How do you protect customer traffic?”
• “What monitoring do you have?”

Evidence:

• DDoS mitigation documentation
• Network diagrams
• Incident logs (DDoS attacks)
• Monitoring dashboards

Focus on Availability: DDoS is a risk to availability. The auditor checks whether you are prepared. You must be able to show: “We had a DDoS attack, we mitigated it within X minutes, and the impact on customers was Y.”

4. Data isolation between customers

Your customers share the same infrastructure. How do you prevent data leaks?

Controls:

• Storage isolation: Separate volumes and encryption keys per tenant
• Database isolation: Separate databases, or strong isolation at schema level
• Backup isolation: The backup of customer A is not accessible to customer B
• Network isolation: VPCs, security groups, firewalls
• Metadata separation: Even metadata (logs, billing) is separated per tenant

What the auditor asks:

• “How do you make sure customer A cannot see customer B’s data?”
• “Show me your storage architecture.”
• “What happens if there is a misconfiguration?”
• “Do you have automated checks on tenant isolation?”

Evidence:

• Architecture diagrams
• Code and configuration reviews: tenant filtering is enforced
• Automated tests: attempts at cross-tenant access (they must fail)
• Findings from penetration tests

5. Access management for customers

Customers have access to your portal, API or infrastructure. How do you manage that?

Controls:

• MFA: Mandatory for all customer accounts
• RBAC: Customers can define roles (admin, user, read-only)
• API keys: Ability to rotate them, with limited permissions
• Access logs: All customer actions are logged
• Session management: Timeouts, secure tokens

What the auditor asks:

• “Show me the login process for customers.”
• “Is MFA enforced?” (yes)
• “Can customers see each other’s data?” (no)
• “Show me the API authentication.”

Evidence:

• Screenshots of the customer portal
• MFA enforcement configuration
• API documentation (authentication requirements)
• Access logs

6. Incident response for infrastructure

Incidents in cloud and hosting have a wider impact (several customers at once).

Controls:

• Incident classification: Severity levels (SEV1, SEV2, and so on)
• Escalation matrix: Who you call for each severity
• Communication with customers: Transparency during incidents (status page)
• Post-mortems: After every major incident, you record the cause
• SLA credits: If an SLA is breached, the customer receives compensation

What the auditor asks:

• “Show me a recent infrastructure incident.”
• “How did you communicate with customers?”
• “What was the cause, and what did you fix?”
• “Show me the post-mortem document.”

Evidence:

• Incident log (last 12 months)
• A sample incident plus its post-mortem
• Communication to customers (updates on the status page)
• Measures taken

A status page is critical: A public status page (StatusPage.io, Atlassian Statuspage) where customers see real-time updates. The auditor expects this for Availability.

7. Capacity planning and scaling

You need to plan ahead. Customer growth and seasonal peaks.

Controls:

• Resource monitoring: CPU, memory, disk and bandwidth per data centre or region
• Forecasting: Quarterly capacity reviews and trend analysis
• Scaling procedures: Auto-scaling where possible, manual scaling documented
• Threshold alerts: 80% capacity means planning an expansion
• Lead times: Know how long it takes to add capacity (ordering and installing hardware)

What the auditor asks:

• “How do you plan capacity?”
• “Show me a recent capacity review.”
• “What happens when you approach your capacity limit?”
• “Have you ever run out of capacity? How did you solve it?”

Evidence:

• Minutes of quarterly capacity reviews
• Resource usage graphs (6-12 months)
• Scaling events (capacity added)
• Communication to customers (if there were capacity problems)

8. Data retention and secure disposal of equipment

Servers and disks are taken out of use. Customer data must be wiped securely.

Controls:

• Data deletion policy: Customer data is deleted within X days after the contract ends
• Disk wiping: DOD 5220.22-M standard or better (at least 3 overwrites)
• Physical destruction: Disks that cannot be wiped are destroyed
• Certificate of destruction: For customers with regulatory requirements
• Disposal log: Keep a record of decommissioned hardware

What the auditor asks:

• “Show me your decommissioning process.”
• “How do you wipe disks?”
• “Show me a recent disposal log.”
• “How do you handle broken disks?”

Evidence:

• Decommissioning procedure
• Example disposal log
• Certificate of destruction (for physical destruction)
• Contracts with suppliers (for outsourced disposal)

Controls that matter especially for cloud

Backup and disaster recovery (very critical)

Why it is extra critical: You host data for hundreds or thousands of customers. Failing backups are a disaster.

Controls:

• Automated daily backups (per customer)
• Off-site storage (another region or provider)
• Encrypted backups (at rest and in transit)
• Regular restore tests: weekly (sample) and monthly (full restore)
• Backup monitoring: an alert when a backup fails
• Retention period: 30 days daily, 12 months weekly

What the auditor checks:

• “Show me 6 months of backup logs.”
• “When was the last restore test?” (it must be recent)
• “Show me a successful restore.” (demo or evidence)
• “What happens when a backup fails?” (alert plus investigation)

Common mistake: Backups run, but they are never tested. A customer asks for a restore and it fails. The auditor hears this story, and it is a major finding. Test your backups consistently.

SLA monitoring (critical for Availability)

Why it is extra critical: You probably have an SLA of 99.9% or 99.95%. The auditor will check this.

Controls:

• External uptime monitoring (not only internal)
• SLA reporting: monthly reports to customers
• Downtime logging: all incidents recorded
• Root cause analysis: for every outage
• SLA credits: an automated or manual process

What the auditor checks:

• “Show me 12 months of uptime data.”
• “Did you meet your SLA?” (if not: why, and what did you do?)
• “Show me the SLA reports sent to customers.”
• “How do you calculate uptime?” (methodology)

Availability targets:

If your SLA is 99.9% and you had 2 hours of downtime in one month, you have breached it. The auditor wants to know: was the customer compensated, and has the cause been fixed?

Change management (extra strict)

Why it is extra critical: Changes affect all customers. A bad change means a major outage.

Controls:

• Maintenance windows: announced at least 72 hours in advance
• Approval: by a senior engineer plus a manager
• Testing: a staging environment that mirrors production
• Rollback plan: always have a rollback ready
• Phased rollout: canary deployments, blue-green
• Monitoring during and after the change: extra vigilance
• Emergency procedure: for critical security patches

What the auditor checks:

• A sample of 20 changes: approval, testing, rollback plan?
• A failed change: how did you roll back, and what was the impact on customers?
• An emergency change: was it a real emergency, and is it recorded?

Best practice: Immutable infrastructure (containers, Kubernetes). Changes are new deployments, not in-place modifications. Rolling back means returning to the old deployment. Much safer.

Scope considerations for cloud providers

What belongs in scope?

Must be included:

• Hosting infrastructure (servers, network, storage)
• Customer portals (billing, management interface)
• APIs for customer management
• Support systems (ticketing, customer communication)

Consider including:

• Monitoring and logging systems
• Backup infrastructure
• Security tools (SIEM, IDS/IPS)

You can exclude (but be careful):

• Internal HR systems (unless HR has access to production)
• Marketing website (separate from the customer platform)
• Development and test environments (if they are fully isolated)

Trust Services Criteria for cloud

Common choice: Security, Availability and Confidentiality

Security: The foundation, you are protected against hackers Availability: Your core value is uptime Confidentiality: Customer data must stay confidential

Also consider: Processing Integrity: If you do billing or metering for customers Privacy: If you collect personal data beyond basic contact details

Re-audit and continuous compliance

Annual renewal: Cloud and hosting environments change often. New data centres, new services, acquisitions. The re-audit must reflect this.

Updating scope: If you launch a new service (for example a managed database), does it need to be in scope for the next audit? Yes, if customers store data in it.

Continuous monitoring: Tools such as Drata and Vanta help, but for infrastructure it is more complex. You will probably need your own scripts to monitor compliance.

SOC 2 costs for cloud providers

Higher than for SaaS: Cloud providers often have higher audit costs because of:

• Physical security that must be audited (visits to data centres)
• More systems in scope
• More complex infrastructure
• Multiple locations (with several data centres)

Indicative costs (Type II):

• Small cloud provider (1 data centre, under 50 employees): €50,000-€80,000
• Medium-sized (2-3 data centres, 50-200 employees): €80,000-€150,000
• Large (multiple regions, 200+ employees): €150,000-€300,000+

Add consultancy, tooling and internal time, and the total comes to €100,000-€400,000+ in the first year. See the costs and timeline for the full overview.

Checklist for cloud providers

Before you start SOC 2:

Physical:

• Data centre access control (badges, visitors, cameras)
• Climate and power systems (fire, cooling, backup power)
• Asset tracking and decommissioning

Infrastructure:

• Hypervisor hardened and patched
• Network segmentation per tenant
• DDoS mitigation
• Firewall rules documented
• IDS/IPS rolled out

Data:

• Tenant isolation tested (penetration tests)
• Encryption at rest and in transit
• Backups automated and tested (restore tests)
• Data deletion procedures

Operations:

• Change management process
• Incident response plan and tests of it
• SLA monitoring and reporting
• Quarterly capacity planning
• Status page for transparency towards customers

Suppliers:

• Upstream providers (ISPs, power, colocation) have SOC 2
• Hardware suppliers documented
• Disposal supplier (if used)

If you have ticked 80% or more of these, you are ready.

More information

• Step-by-step plan: The 12 steps to SOC 2
• Costs and timeline: What it costs
• Trust Services Criteria: The 5 pillars
• Controls: Concrete examples
• For SaaS: SaaS-specific tips