SOC 2 for Infrastructure

SOC 2 for infrastructure companies, platform-scale.

Databases, queues, edge networks, and platforms: your customers run mission-critical workloads on you. Skadi scopes SOC 2 Type II around multi-tenant isolation, data-plane controls, region residency, and the uptime commitments enterprise SREs actually depend on — with a senior CPA who understands control-plane / data-plane separation on day one.

4.9on Trustpilot
Independent SOC 2 Type II
Why this vertical is different

Audit challenges we solve for you.

Control plane vs data plane

Two distinct trust boundaries in one report. Generic auditors conflate them; enterprise reviewers notice immediately and ask.

Multi-region residency promises

If you sell EU-only or US-only guarantees, controls must enforce them and evidence must prove it — architecturally, not on a slide.

Customer-managed keys and workloads

BYOK, CMK, and customer-controlled compute complicate isolation, deletion, and evidence in ways most audit templates do not cover.

Downstream reliance

Your customers' own auditors read your report and CUECs. Ambiguity in the system description propagates into their exception reports — and comes back to you as a support ticket from their auditor.

Where auditors focus

Controls that matter most for your business.

Multi-tenant isolation (CC6.6)

Network segmentation, per-tenant identity boundaries, storage partitioning, and monitoring that would surface cross-tenant access attempts.

Data-plane access controls (CC6.1, C1.1)

Provable no-standing-access from your engineers to customer data, break-glass with auditor-visible logging, and customer notification where required.

Region & residency enforcement (C1.1)

Deployment configurations, routing rules, and access logs demonstrating data stays in committed regions across the full observation window.

Availability & capacity (A1.1–A1.3)

Capacity headroom, chaos/failover testing, incident response with RTO/RPO evidence, and postmortems covering every SLA-relevant incident.

Encryption & key management (CC6.7)

KMS/HSM-backed keys, per-tenant DEKs where applicable, BYOK/CMK flows, and controls proving customer revocation actually renders data unrecoverable.

Change management on the platform (CC8.1)

Elevated review for infra-level changes, staged rollouts, automated rollback, and evidence no ad-hoc changes bypass the pipeline.

Physical and environmental (CC6.4)

Where you operate colocation or edge PoPs, tested physical access controls and environmental monitoring. Cloud-only environments carve out to hyperscaler SOC reports.

Sub-service organization oversight (CC9.2)

Annual review of hyperscaler SOC reports, CUEC tracking, and evidence your team actually operates the complementary controls those reports assume.

Common Type II findings

What actually fails in this vertical.

Real deviations we see in SOC 2 Type II fieldwork — and what your platform and security teams should fix before the observation window starts.

Control plane admin access not gated by JIT

Standing admin on the control plane for a handful of engineers. Move to just-in-time elevation with approval and time-bound scope — auditors expect it for infra companies now.

Evidence to collect
  • JIT tool config (Teleport / AWS IAM Identity Center / Sym)
  • Elevation request log with approver + duration for the window
  • Standing-access policy with JIT-first requirement
  • IAM report showing zero permanent admins on control plane
Tenant data plane logs missing customer identifier

Central logs can't be sliced by customer, so incident scoping requires guesswork. Instrument tenant ID at every layer before the observation window.

Evidence to collect
  • Logging standard requiring tenant_id in every event
  • SIEM query returning per-tenant slice on a sampled service
  • Code review checklist item for tenant tagging
  • Sample incident report scoped by tenant
IaC drift not detected

Terraform is source of truth on paper; console changes happen and stay. Drift detection running continuously with alerting and remediation SLA is the modern control.

Evidence to collect
  • Drift-detection tool config (driftctl / Terraform Cloud / env0)
  • Drift alert history + remediation tickets for the window
  • Policy prohibiting console changes with break-glass process
  • IaC repo protected-branch settings
DR tested at the region, not the customer, level

Failover exercise proves the region comes up, does not prove a specific customer workload recovers within RTO. Test end-to-end and evidence it.

Evidence to collect
  • DR plan with per-customer / per-tier RTO/RPO
  • Executed DR test report including tenant-level validation
  • Runbook for customer-scoped failover
  • Post-test action-item ticket log
Hypervisor/orchestrator patching cadence undocumented

Managed by the platform team by tribal knowledge. Written cadence with evidence of adherence — including out-of-cycle CVE response — is what auditors sample.

Evidence to collect
  • Patch-management policy with cadence + severity SLAs
  • Patch report from the orchestration platform for the window
  • CVE-response ticket for a sampled critical
  • Change tickets for scheduled patch cycles
Physical/colocation attestations not obtained annually

Downstream data-center SOC 2 or ISO 27001 reports not collected and reviewed. Sub-service organization monitoring fails without them.

Evidence to collect
  • Sub-service org register (AWS/GCP/colo) with latest report date
  • Reviewed SOC 2 / ISO 27001 report per provider
  • CUEC review notes documenting management's assessment
  • Ticket for follow-up on any noted exceptions

Why infrastructure SOC 2 is different

When you are the substrate other companies build on, your SOC 2 report becomes evidence in your customers' own audits. That downstream dependency raises the bar significantly. Enterprise SRE and security teams read your report line by line — the system description, the tests performed, and every exception. Vague scoping is not just an audit issue, it is a revenue issue.

The control plane / data plane split

A mature infrastructure SOC 2 describes two distinct trust boundaries. The control plane is your customer-facing surface (APIs, dashboards, billing, provisioning) and is heavy on access, change management, and standard SaaS controls. The data plane is where customer workloads and data live and is heavy on isolation, encryption, monitoring, and — crucially — controls proving your own engineers cannot touch it casually.

Region residency as an auditable control

Selling 'EU data stays in the EU' is not a marketing promise once you are in a SOC 2 audit; it is a control that must be enforced and evidenced. We scope this explicitly: deployment configurations, routing rules, access logs by region, and controls preventing cross-region replication (including backups and telemetry). Enterprise buyers, particularly regulated ones, will ask specifically what evidence you provided.

Complementary User Entity Controls done honestly

Infrastructure reports live and die by their CUECs. Over-broad CUECs ("customer is responsible for all security") get flagged and eroded trust; under-specified ones create ambiguity for your customer's auditor. We draft CUECs that a reviewer can act on — precise, minimal, and honest about the boundary between what you operate and what your customer must.

FAQ

Questions we hear from teams like yours.

Ready to scope your SOC 2 Type II?

Book a call and we'll walk you through timeline, scope, and pricing for your company.

Back to home