Derrick Osei found out how fragile a data center relationship can be on a Tuesday afternoon, three weeks before his employer's biggest renewal was due to close. Derrick is VP of Compliance at Meridian Colocation & Cloud, a mid-sized hosting provider running three facilities — Ashburn, Dallas, and Amsterdam — that host everything from customer-owned cabinets to fully managed bare-metal and IaaS environments. The renewal was a $2.3 million, three-year contract with Solenna Health, a healthtech company that ran its patient-record platform on Meridian's infrastructure.
The problem wasn't a breach, an outage, or a missed patch. It was paperwork — or rather, the absence of the right paperwork. Solenna's own SOC 2 auditor had flagged, during their Type II fieldwork, that Solenna could not adequately describe or test the controls Meridian operated on its behalf. Meridian was a subservice organization in Solenna's system description, but Meridian had never formalized which controls it carried, never published a list of complementary user entity controls, and had no current SOC 2 report of its own that Solenna's auditor could rely on. Solenna's CISO, Marcus Webb, called Derrick directly: "We can't renew until you can show me, in writing, exactly what you're responsible for down there. Right now my auditor is treating your data centers as a black box, and a black box is a qualified opinion waiting to happen."
That call reframed how Derrick thought about compliance. Meridian had always treated physical security and uptime as operational excellence — badges, cameras, generators, service credits. What it hadn't done was translate that operational reality into the specific language customer auditors needed: a defined system boundary, a Trust Services Criteria mapping, a formal subservice organization designation, and a CUEC list customers could hand to their own examiners. Nine months later, Meridian had its first SOC 2 Type II report, a published complementary user entity controls list, and a signed renewal — plus three new contracts that named the report as the reason they'd been shortlisted. This article is the playbook Derrick wishes he'd had on day one.
Who this is for, and what you'll walk away with
This is for compliance, security, and operations leaders at colocation facilities, bare-metal/dedicated server providers, and Infrastructure-as-a-Service (IaaS) companies — anyone whose customers run their own workloads, applications, or virtual machines on infrastructure you physically or logically control. You'll walk away with a working model of which Trust Services Criteria apply to infrastructure providers, how to build the physical, environmental, network, and virtualization controls a Type II audit actually tests, how to handle your role as a subservice organization inside every customer's own report, and how to publish CUECs and CSOCs that make your customers' auditors — and your sales team — happy at the same time.
Why hosting and IaaS providers are a distinct SOC 2 case
Most SOC 2 guidance is written for SaaS companies whose entire "system" is an application running on someone else's cloud. Hosting providers are the inverse: you are the someone else's cloud, or the data center underneath it. You own layers — power, cooling, physical racks, network fabric, and often the hypervisor — that a SaaS company only ever consumes. That changes which Trust Services Criteria matter most, how evidence gets collected, and how your report gets used, because dozens of other companies' own SOC 2 examinations depend on yours.
It's also worth being precise about which flavor of infrastructure provider you are, because the term "hosting provider" covers a wide range of models, and each one changes your control scope.
Model | What you own | What the customer owns | Typical customer |
|---|---|---|---|
Colocation (colo) | Facility, power, cooling, physical security, cross-connects | Servers, network gear, OS, applications | Enterprises with owned hardware, MSPs |
Bare-metal / dedicated hosting | Facility + physical servers + network | OS, applications, sometimes hypervisor | Mid-market companies avoiding public cloud |
IaaS (compute/storage/network) | Facility + hardware + hypervisor + virtual network | Guest OS, applications, data | SaaS companies, startups, enterprises |
Managed hosting | All of the above + OS patching, backups | Applications, data | Companies wanting hands-off infrastructure |
This is a deliberately different focus from SOC 2 for Cloud Service Providers, which centers on the hyperscale, API-driven platform layer (compute provisioning, managed services, developer tooling). This article is about the physical and infrastructure layer underneath that — the data center, the racks, the power, the network fabric, and the virtualization layer — whether it's sold as colocation, bare metal, or IaaS. A large hyperscale CSP and a regional colocation provider both need SOC 2, but a colo provider's report leans far more heavily on physical and environmental evidence, while a CSP's report leans more on API-layer access controls and platform automation. Many organizations are, in practice, both — a CSP built on top of owned data centers — in which case both articles apply. If you're also weighing certification alongside attestation, What Is ISO 27001 is a useful primer before you decide whether to pursue one framework or both.
"I used to think our compliance story was 'we have good uptime.' Auditors don't care about your marketing uptime number. They care whether you can produce a badge log, a change ticket, and a capacity report for the exact three months they're testing." — Derrick Osei, VP of Compliance, Meridian Colocation & Cloud
Mapping the infrastructure stack you actually own
Before selecting Trust Services Criteria, map exactly which layers of the stack are in your control — because your system description has to match reality precisely, and a mismatch here is the single most common reason customer auditors reject a subservice organization's documentation.
Layer | Colocation | Bare-metal hosting | IaaS |
|---|---|---|---|
Physical building & perimeter | Provider | Provider | Provider |
Power, cooling, fire suppression | Provider | Provider | Provider |
Rack/cabinet physical access | Provider (shared with customer) | Provider | Provider |
Network cabling & cross-connects | Provider | Provider | Provider |
Physical servers | Customer | Provider | Provider |
Hypervisor / virtualization | N/A | Rare | Provider |
Guest operating system | Customer | Customer or provider (managed) | Customer |
Applications & data | Customer | Customer | Customer |
The narrower your owned layers, the narrower — but not smaller in rigor — your control set. A pure colo provider still needs airtight physical and environmental controls even though it never touches a customer's operating system. An IaaS provider adds hypervisor isolation, virtual network segmentation, and control-plane access on top of everything a colo provider does.
Choosing Trust Services Criteria: Security plus Availability, almost always
Every SOC 2 report includes the Common Criteria (Security) — there's no version of a hosting provider's report without it. The question is which optional categories to add, and for infrastructure providers the answer is nearly always the Availability category, because uptime is the core commitment customers are buying.
Trust Services Criteria | Applicable to hosting/IaaS? | Why |
|---|---|---|
Security (Common Criteria) | Always required | Physical/logical access, change management, monitoring |
Availability | Almost always included | Uptime SLAs, redundancy, capacity, recovery are core value props |
Confidentiality | Often included | Customer data, configs, and network designs handled in cabinets/hypervisors |
Processing Integrity | Rarely included | Provider doesn't process customer application logic |
Privacy | Rarely included | Provider typically doesn't determine use of personal data |
Confidentiality is worth a closer look if you store customer configuration data, hold escrowed credentials, or provide managed services that touch customer data directly (e.g., managed backups). Processing Integrity and Privacy are usually out of scope because the hosting provider doesn't decide how customer data is processed or used — that determination sits with the customer, who is the data controller in most cases.
"The mistake I see most often is a colo provider trying to scope Processing Integrity because a salesperson thought a bigger report looks more impressive. It doesn't. It just gives the auditor more to test that has nothing to do with what you actually control." — Lena Cho, Partner, Cho & Averill CPAs
Physical security: the control set customers actually check first
Physical security is where hosting-provider SOC 2 reports diverge most sharply from application-layer SOC 2 reports. Under the Common Criteria, CC6.4 addresses physical access restrictions to facilities, backup media, and infrastructure components — and for a hosting provider, this is the control auditors and prospective customers scrutinize hardest, because it's the one control category a customer has almost no ability to verify for themselves once their gear is in your cage.
Physical control area | What auditors test | Common evidence |
|---|---|---|
Perimeter access | Fencing, gated entry, vehicle barriers | Site survey photos, access logs |
Building entry | Mantraps, turnstiles, guard checkpoints | Badge system exports, guard logs |
Data hall / cage access | Biometric or two-factor badge access, escort policy for visitors | Access control system reports, visitor logs |
Cabinet/rack-level access | Locking cabinets, keyed access for shared cages | Cabinet access logs, key issuance records |
Video surveillance | CCTV coverage of entry points, data halls, loading docks | Retention policy, sample footage review |
Access review cadence | Periodic review and revocation of physical access rights | Quarterly access review sign-offs |
Termination handling | Timely badge/key deactivation on employee or vendor offboarding | HR/security ticket correlation |
We cover the full physical control model in depth in SOC 2 Physical Security: Data Center and Office Protection — read that alongside this article if you're building your control set from scratch, since physical security for a data center operator is materially more complex than physical security for a company leasing office space.
Environmental controls: the infrastructure customers can't self-audit
Environmental controls sit under the same Common Criteria umbrella but focus on the systems that keep hardware running rather than the systems that keep people out. For a hosting provider, this is arguably the highest-stakes category, because environmental failure — not a hacker — is what actually takes most data centers offline.
Environmental control | What it protects against | Typical evidence |
|---|---|---|
Redundant power feeds (utility + generator) | Utility outage | Generator test logs, fuel contracts, ATS test records |
Uninterruptible power supply (UPS) | Power transfer gaps | UPS runtime tests, battery replacement schedule |
Precision cooling (CRAC/CRAH units) | Overheating, thermal shutdown | Temperature/humidity logs, cooling capacity reports |
Fire detection and suppression | Fire damage | Inspection certificates, suppression system test records |
Water/leak detection | Flooding, cooling-system leaks | Sensor logs, incident tickets |
Seismic/structural bracing (where applicable) | Structural failure | Engineering certification |
Environmental evidence collection is fundamentally different from application-layer evidence: it comes from building management systems (BMS), generator logs, and third-party inspection certificates rather than from a SaaS platform's audit log. Build a calendar for recurring environmental evidence (generator load tests are often monthly, fire suppression inspections often annual) well before your audit window opens — this is the category where "we'll pull it later" evidence gaps are most common. We go deeper on the full control catalog in SOC 2 Environmental Controls: Infrastructure Protection.
"Cameras and badges are the easy part. What kept me up at night before our first Type II was proving, with paper, that every generator test actually happened on schedule for the full nine-month window — not just that we own generators." — Priya Nathan, Director of Data Center Operations, Meridian Colocation & Cloud
Availability criteria: turning uptime marketing into audit evidence
The Availability category has three points of focus that map cleanly onto what a hosting provider already does operationally — the work is translating operations into evidence an auditor can test against a defined availability commitment.
Availability point | Focus | Hosting-provider evidence |
|---|---|---|
A1.1 | Capacity management — current usage vs. capacity, forecasting | Power/space/network capacity reports, forecasting models |
A1.2 | Environmental protections, backup, and recovery infrastructure | Redundant power/cooling design, backup infrastructure inventory |
A1.3 | Recovery plan testing | DR test results, failover drill reports, tabletop exercise records |
Capacity management (A1.1) is frequently under-documented at hosting providers because it lives in operations spreadsheets rather than a formal control. Auditors want to see that you actively track power draw, rack space, and network bandwidth against defined thresholds and that you have a documented process for triggering capacity expansion before you hit a ceiling — not just that you happen to have room.
Service level agreements and how they connect to Availability evidence
Your commercial SLA and your SOC 2 Availability scope should tell the same story, even though they serve different audiences — the SLA is a contractual promise with service credits, while the SOC 2 report is independent evidence that you have the controls to keep that promise.
SLA tier | Uptime commitment | Typical redundancy design | Service credit for breach |
|---|---|---|---|
Standard colocation | 99.9% | N+1 power/cooling, single utility feed | 5% monthly credit per hour of downtime |
Premium colocation | 99.99% | 2N power, dual utility feeds, diverse carriers | 10% monthly credit per hour |
Bare-metal hosting | 99.95% network/power | N+1 infrastructure, hardware replacement SLA (4hr) | Prorated daily credit |
IaaS compute | 99.99% (per-instance or per-region) | Multi-AZ/multi-host redundancy, live migration | Service credit tiers by breach severity |
If your SLA promises 99.99% but your Availability control narrative only supports N+1 redundancy and manual failover, that gap is exactly what a skeptical customer's security questionnaire — or your own auditor — will find. Align the two before you publish either.
Redundancy architecture: the diagram customers actually want to see
Sales teams often describe redundancy in prose ("fully redundant power and cooling"). Auditors and technically sophisticated customers want the architecture. A simple layered diagram, kept current and referenced in your system description, does more to build trust than another paragraph of adjectives.
flowchart TB
A[Utility Feed A] --> C[Automatic Transfer Switch]
B[Utility Feed B] --> C
C --> D[UPS Bank - N+1]
G[Generator Plant - N+1] --> C
D --> E[Power Distribution Units]
E --> F[Customer Racks / Cages]
H[Chilled Water Plant - N+1] --> I[CRAC/CRAH Units]
I --> F
J[Carrier 1] --> K[Core Network Switch Fabric - Redundant]
L[Carrier 2] --> K
K --> FRedundancy tier (industry-standard reference) | Concurrent maintainability | Typical fault tolerance |
|---|---|---|
Tier I | No | Single path for power/cooling |
Tier II | No | Redundant components, single path |
Tier III | Yes | Multiple paths, one active |
Tier IV | Yes | Multiple active paths, fault-tolerant |
These industry-standard data center tier definitions aren't a SOC 2 requirement, but citing which tier your facility is designed to (or certified against) gives auditors and customers a shared vocabulary for the redundancy claims in your system description.
Disaster recovery and business continuity for physical facilities
Disaster recovery for a hosting provider means something more physical than it does for a SaaS company: facility-level failover, not just database failover. Your business continuity plan needs to address scenarios a pure software company never faces — a regional power grid failure, a fiber cut affecting an entire metro, or a facility becoming physically inaccessible.
Scenario | Recovery approach | Target RTO | Target RPO |
|---|---|---|---|
Single power feed loss | Automatic transfer to redundant feed/generator | Seconds | N/A |
Cooling unit failure | Failover to redundant CRAC/CRAH unit | Minutes | N/A |
Carrier/fiber cut | Automatic reroute via diverse carrier path | Seconds–minutes | N/A |
Full facility outage | Customer failover to secondary site (if multi-site) | Hours (customer-dependent) | Customer-dependent |
Regional disaster | Facility evacuation, customer notification, extended outage | Provider-defined per contract | Provider-defined per contract |
Be explicit in your system description about which recovery scenarios you own versus which require customer action — a facility-level failover between your own sites is your responsibility; a customer's application-level failover across two of your regions is generally a shared responsibility unless you sell it as a managed service.
Network security controls at the infrastructure layer
Network security for a hosting provider spans two very different zones: the provider network (the fabric connecting facilities, carriers, and customer connections) and, for IaaS, the virtual network layer customers configure themselves.
Control area | Purpose | Evidence |
|---|---|---|
Perimeter firewalls / border routers | Filter traffic entering the facility network | Firewall rule reviews, change tickets |
DDoS mitigation | Absorb/filter volumetric attacks before they hit customer traffic | Scrubbing center logs, mitigation event reports |
BGP route monitoring | Detect route hijacks/leaks affecting customer IP space | Route monitoring alerts, RPKI configuration |
Separate management, customer, and out-of-band networks | Network diagrams, VLAN/segment configs | |
Cross-connect and interconnect controls | Ensure physical/logical cross-connects are authorized | Cross-connect order and approval records |
Intrusion detection on provider network | Detect anomalous activity on shared infrastructure | IDS/IPS alert logs, tuning records |
The out-of-band management network deserves special attention in audits: if a customer's compute or storage can be managed through a network path the customer itself can't see or monitor, auditors will want strong evidence that access to that path is tightly controlled, logged, and reviewed — it's one of the highest-trust, lowest-visibility parts of your environment.
Virtualization and multi-tenancy: isolation is the control that matters most
For IaaS and virtualized bare-metal providers, the hypervisor is the single most important trust boundary in the entire environment. A failure of tenant isolation at the hypervisor layer is the hosting-provider equivalent of a SaaS company's cross-tenant data leak — and it's the control customers' own auditors ask about most persistently when a subservice organization is an IaaS provider.
Multi-tenancy control | Purpose | Evidence |
|---|---|---|
Hypervisor hardening & patching | Reduce attack surface of the virtualization layer | Patch cadence records, hardening baseline (CIS or vendor benchmark) |
VM/container escape protections | Prevent one tenant from reaching another's workload | Vulnerability scan results, isolation test results |
Virtual network isolation (VLAN/VXLAN/SDN) | Separate tenant traffic logically | Network config reviews, segmentation test results |
Storage isolation (SAN/NAS multi-tenancy) | Prevent cross-tenant data access at the storage layer | Access control config, storage audit logs |
Resource quota enforcement | Prevent one tenant from starving others ("noisy neighbor") | Capacity/QoS monitoring reports |
Secure decommissioning of reused hardware | Prevent data remanence when hardware is reassigned | Wipe/cryptographic erasure logs |
Multi-tenancy isolation failures are rare in well-run environments but catastrophic in customer trust terms when they happen — a single noisy-neighbor or side-channel incident at a competitor is often the single biggest driver of new SOC 2 sales inquiries for well-controlled providers, a pattern we'll return to in the case studies below.
Being the subservice organization: the role that shapes everything else
This is the concept that made Derrick's phone ring. A subservice organization is a vendor whose controls a service organization (your customer) relies on to meet its own commitments. When your customer's auditor examines their SOC 2, your infrastructure controls are either described and tested through the inclusive method, or excluded and assumed through the carve-out method — and which one applies changes what you owe your customers.
Factor | Carve-out method | Inclusive method |
|---|---|---|
Whose controls appear in the customer's report | Only the customer's own controls; yours are excluded and assumed | Yours are described and tested directly in the customer's report |
What you need to provide | A published CUEC/CSOC list, and often your own SOC 2 report | Direct participation: interviews, evidence, sometimes a site visit by the customer's auditor |
Effort for you | Lower — no direct involvement in customer's audit fieldwork | Higher — you're effectively part of the customer's audit scope |
Effort for the customer's auditor | Must independently gain assurance over your controls (usually via your own SOC 2 report) | Tests your controls directly as part of the engagement |
Best fit | Providers serving many customers who each need independent assurance | A small number of very large, high-value customers requiring direct assurance |
Most hosting providers should default to carve-out backed by their own strong SOC 2 report — it scales across hundreds of customers without requiring you to open your facilities to dozens of individual customer audit teams. Reserve the inclusive method for a small number of strategic accounts where the commercial relationship justifies the operational overhead.
"We publish our own SOC 2 Type II specifically so our customers' auditors never have to call us. Carve-out only works smoothly if the thing you're carving out is backed by something a CPA firm will actually accept as sufficient evidence." — Derrick Osei, VP of Compliance, Meridian Colocation & Cloud
How you appear inside a customer's SOC 2 report
Even under carve-out, your customer's system description will name you — typically in a section describing subservice organizations and how their controls relate to the customer's own control environment. Get ahead of this by giving customers exact, reusable language rather than making their compliance team reverse-engineer it from your marketing site.
Report section | What customers need from you |
|---|---|
Subservice organization description | A short, accurate paragraph describing what you provide (facility, power, network, compute) |
Method disclosure | Confirmation of carve-out or inclusive status |
Reliance statement | Reference to your current SOC 2 report period and scope, if carve-out |
CUEC cross-reference | Your published CUEC list, mapped to the criteria they support |
Contact for auditor inquiries | A named compliance contact for direct auditor questions during their fieldwork |
Publishing a one-page "subservice organization summary" PDF that customers can drop directly into their own audit packages removes friction at exactly the moment your customer's auditor is deciding whether your carve-out is sufficient — and it's one of the highest-leverage documents a hosting provider can produce.
CUECs and CSOCs: the two lists every hosting provider must publish
Complementary user entity controls describe what your customers must do for your controls to work as intended. Complementary subservice organization controls describe what controls you assume are operated by your own upstream vendors under a carve-out. Hosting providers need both lists, because you sit in the middle of the chain — a subservice organization to your customers, and a service organization relying on your own subservice vendors.
CUEC (customer's responsibility) | Why it matters |
|---|---|
Physically secure customer-owned equipment inside shared cages beyond provider-controlled access points | Provider secures the cage; customer secures what's inside it |
Maintain an accurate authorized-visitor list for facility escort requests | Provider enforces escort; customer defines who's authorized |
Configure guest OS and application-layer security controls | Provider secures hypervisor/network; customer secures what runs on it |
Manage their own encryption keys for customer-controlled encryption | Provider may offer HSM access; customer controls key policy |
Report planned high-load events in advance for capacity planning | Provider manages baseline capacity; customer must flag spikes |
Maintain current emergency contact information | Provider needs a live contact during incidents |
CSOC (assumed of provider's own vendors) | Why it matters |
|---|---|
Utility provider maintains contracted power delivery reliability | Facility redundancy design assumes baseline utility reliability |
Upstream network carriers maintain contracted bandwidth and diverse routing | Network redundancy assumes carrier-level path diversity |
Hardware vendors deliver firmware security patches in a timely manner | Hypervisor/firmware hardening depends on vendor patch availability |
Building/property management maintains structural and life-safety systems | Physical security assumes sound building infrastructure |
Publish both lists on your trust portal and reference them explicitly in your system description — this is the artifact Solenna's auditor was missing when they called Derrick, and it's the single highest-value document a hosting provider can produce for its customer base at large.
Colocation, bare-metal, and IaaS: where control scope diverges most
Zooming back out, here's how the three dominant hosting models compare across the specific control questions auditors ask most often.
Question | Colocation | Bare-metal hosting | IaaS |
|---|---|---|---|
Who patches the OS? | Customer | Customer (or provider, if managed) | Customer |
Who manages the hypervisor? | N/A | Rarely present | Provider |
Who controls physical rack access? | Provider (shared/escorted for customer's own techs) | Provider only | Provider only |
Is the customer ever on-site? | Frequently | Rarely | Never |
Primary isolation boundary | Physical cage/cabinet | Physical server | Hypervisor/virtual network |
Most-tested Common Criteria points | CC6.4 (physical access) | CC6.4, CC7.1 (vulnerability mgmt on managed OS) | CC6.1, CC6.6, CC7.2 (logical/network monitoring) |
Typical CUEC volume | High (customer manages most of the stack) | Medium | Lower (provider manages more layers) |
Colocation customers retain the most responsibility and generate the longest CUEC lists; IaaS customers retain the least, which shifts more of the audit burden — and more of the trust — onto the provider's own control set.
Change management for infrastructure that customers can't see
Change management at a hosting provider covers changes a customer never approves and often never even notices: firmware updates, hypervisor patches, network fabric changes, and power/cooling system maintenance. Because these changes can affect availability for many customers simultaneously, the control bar is higher than typical application change management.
Change type | Risk if uncontrolled | Control expectation |
|---|---|---|
Hypervisor patching | Multi-tenant outage or instability | Staged rollout, maintenance windows, rollback plan |
Network fabric changes | Widespread connectivity loss | Peer review, change advisory board, off-peak scheduling |
Firmware updates | Hardware instability across racks | Vendor-validated firmware, canary deployment |
Power/cooling system maintenance | Facility-wide availability risk | Advance customer notification, redundancy verification before work begins |
Emergency changes | Bypassing normal review under time pressure | Documented emergency-change process with after-the-fact review |
Customer notification policy deserves its own line item: even changes that shouldn't cause visible impact (because redundancy should absorb them) should be communicated in advance for anything touching shared power, cooling, or network infrastructure — auditors want to see that notification is a defined, followed process, not an ad hoc courtesy.
Incident response and customer notification obligations
Incident response at a hosting provider has to account for incidents that are entirely physical (a cooling failure, a break-in attempt) alongside classic cyber incidents. Incident response processes need to cover both, with notification timelines that satisfy contractual SLAs and, where applicable, downstream regulatory obligations your customers carry (like breach notification laws that flow through to them).
Incident type | Detection source | Customer notification expectation |
|---|---|---|
Physical security breach attempt | CCTV/access control alerts | Immediate notification if customer space potentially affected |
Power/cooling event | BMS alerts, generator/UPS monitoring | Real-time status page + post-incident report |
Network/DDoS event | IDS, carrier alerts, NOC monitoring | Real-time status page + root cause summary |
Hypervisor-layer security event | Host-based monitoring, vendor advisories | Direct notification to affected tenants only, per isolation scope |
Suspected data exposure | Log review, customer report | Formal incident notification per contract/SLA timeline |
Build a status page and an incident notification template before you need them — the worst time to design a customer communication process is during the incident itself, and auditors will specifically ask to see evidence that your process was followed, not just that it exists on paper.
Managing your own upstream vendors
You're a service organization too, relying on your own subservice organizations: the utility company, bandwidth carriers, hardware and firmware vendors, and possibly a building owner if you lease rather than own your facilities. Vendor risk management at this layer looks different from typical SaaS vendor management — you can't easily switch utility providers, but you can and should document contractual reliability commitments, monitor performance, and build redundancy that reduces reliance on any single vendor's availability.
Upstream vendor type | Risk managed | Typical control |
|---|---|---|
Power utility | Grid outage | Dual feeds where available, generator backup, documented SLA |
Network carriers | Fiber cuts, carrier outage | Multiple diverse-path carriers, BGP failover |
Hardware/firmware vendors | Vulnerable or defective components | Vendor security advisory monitoring, patch validation |
Building owner (if leased) | Structural/life-safety failures | Lease-level SLAs, joint incident response procedures |
Collecting audit evidence for a facility, not just a codebase
Evidence collection is where hosting providers most often underestimate the lift of a first SOC 2 audit. SaaS companies can automate huge swaths of evidence collection from cloud-native logging. Hosting providers have to pull evidence from building management systems, physical access control platforms, generator monitoring tools, and paper-based vendor certificates that were never designed with audit sampling in mind.
Evidence type | Typical source system | Collection challenge |
|---|---|---|
Badge access logs | Physical access control platform | Retention policy often shorter than audit period |
Generator/UPS test records | BMS or manual logs | Historically paper-based at older facilities |
Fire suppression inspection certs | Third-party inspection vendor | Annual cadence may not align with audit window |
Temperature/humidity logs | Environmental monitoring system | High data volume, needs sampling strategy |
Change tickets for infrastructure | ITSM/change management tool | May be split across facility and IT teams |
Vulnerability scan results (hypervisor/network) | Vulnerability management platform | Needs clear scoping to in-scope infrastructure |
Start evidence-mapping at least two full quarters before your intended audit start date, and assign a named evidence owner per system — generator logs and badge logs often live with facilities teams who have never interacted with a compliance program before, and that handoff takes longer than most first-time hosting providers expect.
Common audit findings for hosting providers — and how to close them
Across first-time Type II audits for infrastructure providers, the same handful of exceptions recur.
Common finding | Root cause | Remediation |
|---|---|---|
Incomplete physical access review evidence | Quarterly access reviews performed but not documented/signed | Formalize a review template with sign-off and retention |
Generator/UPS test gaps | Tests performed but logs inconsistent or missing | Centralize logs in a single system, assign an owner |
Missing CUEC/CSOC documentation | Never formally published | Draft, publish, and reference in system description |
Undocumented emergency changes | Emergency changes made without after-the-fact review | Formalize an emergency-change process with mandatory review |
Hypervisor patch cadence not evidenced | Patching done informally, no tracked SLA | Define a patch SLA, track compliance in ticketing |
Vendor risk management not formalized for utilities/carriers | No documented oversight of upstream providers | Build a subservice/vendor risk register with review cadence |
Most of these are documentation and process-formalization gaps rather than genuine control failures — the underlying operational discipline usually already exists at a well-run facility. The work is making that discipline legible to an outside auditor.
Cost and timeline for a hosting provider's first SOC 2
Costs run somewhat higher than a comparable SaaS company's first SOC 2, driven by the physical evidence-gathering lift and, often, multiple in-scope facilities. Run your own numbers through the SOC 2 Cost Calculator before you scope a statement of work with an audit firm.
Phase | Typical duration | Illustrative cost range |
|---|---|---|
Readiness assessment / gap analysis | 4–8 weeks | $15,000–$40,000 |
Remediation (policy, evidence systems, CUEC/CSOC drafting) | 3–6 months | $20,000–$75,000 (internal + tooling) |
Type I audit (optional) | 2–4 weeks fieldwork | $20,000–$45,000 |
Type II observation period | 3–12 months (12 typical after year one) | N/A (elapsed time) |
Type II audit fieldwork | 4–8 weeks | $35,000–$80,000 |
Additional facilities beyond the first | Adds to fieldwork scope | +$8,000–$20,000 per facility |
Multi-facility providers should expect the auditor to sample across sites rather than fully test every facility every year, but each additional facility with materially different physical control implementations adds fieldwork time and cost. Standardizing physical and environmental control design across facilities pays for itself at audit time.
Building the customer-facing assurance package
Your SOC 2 report itself is restricted-use, but the artifacts around it can — and should — do commercial work. Package them together as a single, easy-to-request bundle rather than making prospects chase down each piece separately.
Artifact | Purpose | Distribution |
|---|---|---|
SOC 2 Type II report | Full assurance for serious prospects/customers under NDA | Trust portal, gated request |
CUEC/CSOC published list | Enables customer auditors to complete their own testing | Trust portal, public or gated |
Subservice organization summary (one-pager) | Drop-in language for customer system descriptions | Trust portal, public |
Redundancy architecture summary | Sales and technical due diligence | Trust portal, public |
SLA and service credit terms | Contractual clarity, ties to Availability scope | Contract/trust portal |
Status page / incident history | Ongoing transparency, supports Availability narrative | Public |
Case study: Meridian Colocation & Cloud — from black box to renewed and expanded
Meridian's path from Derrick's fateful phone call to a signed renewal took nine months. The compliance team started by formally defining the system boundary across all three facilities, mapped every physical and environmental control to the Common Criteria and Availability points of focus, and — critically — drafted and published a CUEC/CSOC list for the first time in the company's history. They completed a Type I report in month four to give Solenna's auditor interim assurance, then completed a clean Type II report by month nine. The $2.3 million renewal closed on schedule, and within the following two quarters Meridian closed three additional contracts worth $1.1 million in combined new annual revenue, each of which named the published SOC 2 report and CUEC list as a top-three reason Meridian made the shortlist.
"Solenna's renewal is what forced the work, but the report is what's actually generating pipeline now. Our sales team asks for the trust portal link before they ask for pricing." — Derrick Osei, VP of Compliance, Meridian Colocation & Cloud
Case study: Ironhold Data Centers — a rough first Type II becomes a clean second one
Ironhold Data Centers, a bare-metal and dedicated-server provider serving mid-market manufacturing and logistics clients, went into its first Type II audit confident and came out with four exceptions: incomplete physical access review sign-offs (CC6.4), inconsistent generator test logging (A1.2), no evidence of recovery plan testing during the audit period (A1.3), and no published CUEC list. Rather than treat the qualified opinion as a failure, founder Tobias Reyes used it as a remediation roadmap. Over the following five months, Ironhold centralized environmental logging into a single system, formalized quarterly access reviews with mandatory sign-off, ran and documented a full DR failover test, and published its first CUEC list. The second Type II audit came back clean, and Ironhold used the turnaround story directly in enterprise sales conversations, closing $640,000 in new annual recurring revenue from prospects who had explicitly required SOC 2 as a shortlisting criterion.
"The first report wasn't a disaster, it was a to-do list with a CPA firm's signature on it. Enterprise buyers actually responded well to us showing the qualified opinion and then the clean one twelve months later — it proved we fix what we find." — Tobias Reyes, Founder, Ironhold Data Centers
Case study: Cascadia Cloud Infrastructure — turning a competitor's incident into a retention story
Cascadia Cloud Infrastructure, a multi-tenant IaaS provider, watched a competitor suffer a widely discussed noisy-neighbor and isolation incident that triggered a wave of customer security reviews across the industry. Cascadia's head of platform security, Ava Sundstrom, used the moment to proactively share Cascadia's own hypervisor hardening evidence, tenant isolation test results, and current Type II report with its full customer base rather than waiting for questions to arrive. Twelve customers representing $3.4 million in combined annual contract value had begun evaluating alternative providers in the weeks after the competitor's incident; all twelve stayed after reviewing Cascadia's documentation, and two expanded their footprint within the quarter. Cascadia now uses the inclusive method for its largest three accounts at the network layer while remaining carve-out, backed by its published report, for the rest of its customer base.
"Our isolation controls didn't change because of a competitor's incident. What changed was that we stopped assuming customers would trust us by default and started proving it before they asked." — Ava Sundstrom, Head of Platform Security, Cascadia Cloud Infrastructure
SOC 2 as a competitive differentiator, not just a customer requirement
It's tempting to treat SOC 2 as a compliance tax hosting providers pay to keep enterprise deals moving. The providers who get the most value out of it treat it differently: as the mechanism that turns operational excellence you already have — redundant power, hardened hypervisors, rigorous physical access control — into something a prospect's procurement and security teams can actually verify without a site visit. In infrastructure sales, trust is the product as much as the rack space or the compute is. A published Type II report, a clear CUEC list, and a clean subservice organization story shorten security review cycles, reduce the number of custom questionnaires your team fields, and — as Meridian, Ironhold, and Cascadia all found — become a direct line item in why deals close. The providers still treating their reports as a defensive document to produce only when asked are leaving that advantage on the table.
If you're building or maturing a SOC 2 program for a colocation, bare-metal, or IaaS environment, PentesterWorld's compliance team has run this exact playbook across facilities with very different physical designs and customer bases. Explore our SOC 2 Readiness Checklist to benchmark where your physical, environmental, and availability controls stand today, work through the SOC 2 Trust Services Criteria Mapping Template to scope your report correctly the first time, and use the SOC 2 Control Matrix / RACI Template to assign clear ownership across facilities, network, and security teams before your auditor ever walks in the door.