Choosing a SOC 2 Type II Hosting Provider: What to Actually Look For

If you’re staring down your first SOC 2 Type II audit, the cloud-hosting market probably looks like a wall of identical badges. Every provider claims compliance. Few can tell you what theirs actually covers — and the difference between “we host compliant workloads” and “we are SOC 2 Type II attested” is the difference between inheriting controls and writing them from scratch.

This is a practical guide to evaluating a SOC 2 Type II hosting provider. Not what SOC 2 is in the abstract — you can read AICPA documentation for that — but what it means when you’re the one signing the contract, and what to actually ask before you do.

What “SOC 2 Type II” actually means for your hosting provider

SOC 2 is an attestation framework developed by the AICPA. It evaluates a service organization’s controls against five Trust Services Criteria. It is not a certification, and there is no federal body that grants it. A licensed CPA firm audits the provider and issues a report.

The distinction that matters most in practice is Type I vs. Type II:

• Type I confirms that controls are designed appropriately on a specific date. A provider can earn a Type I in a few months. It tells you very little.
• Type II confirms that those controls operated effectively over a period, usually six to twelve months. It requires the auditor to pull evidence — access logs, change tickets, incident reports — and verify the controls actually ran as documented.

When a hosting provider claims “SOC 2 compliance” without specifying the type, assume Type I until proven otherwise. For serious buyers — financial services, insurance, logistics — only Type II counts.

The five Trust Services Criteria, translated

A SOC 2 Type II report tests controls against five categories. Not every provider includes all five. The ones they include are called “in scope” for that report.

1. Security (required for every SOC 2 report)

The baseline. Access control, change management, incident response, vulnerability management, physical security. Every SOC 2 report includes Security. If a provider’s report only includes Security and nothing else, that is a signal — not a problem by itself, but a question to ask.

What a good Security section looks like in practice: named individuals responsible for each control, documented review cadences, and evidence that access reviews actually happen (not just that a policy exists).

2. Availability

Uptime, capacity management, environmental protections, disaster recovery. If your workload has an uptime SLA or a disaster-recovery obligation to your own customers, you want Availability in scope — otherwise the provider’s SOC 2 says nothing about whether their DR plan actually works.

3. Processing Integrity

Data is processed completely, accurately, timely, and with authorization. Usually relevant for transaction-processing systems — payment workflows, data pipelines, anything where silent corruption is the failure mode. Many hosting-infrastructure providers exclude this one because their platform doesn’t transform data. That’s legitimate. But if you’re running financial transactions, ask whether your internal processing-integrity controls can inherit anything from the provider.

4. Confidentiality

Data designated as confidential is protected. This is about data classification, encryption, and retention/destruction controls. For any regulated workload, Confidentiality should be in scope.

5. Privacy

Personal information is collected, used, retained, disclosed, and disposed of in accordance with stated commitments. Often more relevant to SaaS providers than infrastructure ones — but if your hosting provider’s staff can access your data during support or troubleshooting, Privacy matters.

The questions that actually reveal a provider’s posture

Vendor questionnaires are mostly theater. Here are five questions that force a real answer.

1. “Can I see your current SOC 2 Type II report, under NDA?”

The only right answer is yes. A SOC 2 Type II report is meant to be shared with customers and their auditors — that’s its entire purpose. Providers who won’t share theirs are either in Type I territory, have findings they’d rather you not read, or don’t have a report at all.

When the report arrives, check:

• The reporting period. Is it current? A report whose period ended ten months ago needs a bridge letter from the provider covering the gap to today.
• The auditor’s opinion. Look for “unqualified.” A qualified opinion means the auditor found material exceptions — not disqualifying, but you’ll want to read exactly what they were.
• Exceptions and management responses. Every report has at least a handful. The question isn’t whether the provider has any, but whether management’s response actually addressed the root cause.

2. “Which Trust Services Criteria are in scope?”

At minimum for regulated workloads: Security, Availability, Confidentiality. If the report only includes Security, ask why and what that means for your inheritance of controls.

3. “Which subservice organizations do you carve out?”

Most hosting providers depend on upstream parties — datacenters, backup providers, identity systems. A SOC 2 report either includes those subservice organizations (their controls are tested alongside the provider’s) or carves them out (the report explicitly excludes them, and you’re expected to verify those subservices separately).

Carve-outs aren’t wrong. But if your provider carves out their datacenter and can’t point you to the datacenter’s own SOC 2 report, you have a gap in your inheritance chain that your auditor will find.

4. “What is your complementary user entity controls (CUEC) list?”

Every SOC 2 report includes a CUEC list — the controls the provider expects you to operate for their controls to be effective end-to-end. A good provider has thought carefully about this list and can walk you through it. A bad one will send you a generic boilerplate.

You should plan to map every CUEC to a control you actually perform. This is the most overlooked piece of SOC 2 inheritance.

5. “Walk me through how you’d respond to an auditor’s request for evidence.”

This question separates providers who’ve been through real audits from ones who’ve only earned the badge. The right answer sounds like: “We have a documented customer audit support process. You email compliance@, we send you the report and bridge letter within two business days, and if your auditor has follow-up requests we have a named contact who handles those.”

If the response is vague or requires escalation to sales, expect friction in your audit.

”SOC 2 aligned” vs. “SOC 2 attested” — know the difference

Watch the verbs on provider marketing pages. These three phrases mean very different things:

• “SOC 2 attested” — The provider has a current SOC 2 report issued by a CPA firm. Real.
• “SOC 2 compliant” — Ambiguous. Sometimes means the above; sometimes means “we think we’d pass.”
• “SOC 2 aligned” or “SOC 2 capable” — Usually means no report exists. The provider has adopted some of the practices but hasn’t been audited.

“Aligned” isn’t worthless — it’s better than nothing, and some small providers are genuinely working toward their first Type I. But it is not interchangeable with attested, and you cannot inherit controls from a claim.

How the audit actually plays out when hosting is private cloud

If you’re running on a single-tenant private cloud, your SOC 2 audit looks different from a shared-cloud audit — and usually much easier.

On a hyperscaler, your auditor will ask you to demonstrate things like:

• How you isolate your data from other tenants
• How you prove the provider’s employees can’t access your production systems
• How you verify the provider’s underlying controls when you have no visibility into their stack

Most of those questions end with you handing over an AWS, Azure, or GCP SOC 2 report and a written statement of how their shared responsibility model applies to you. Functional, but indirect.

On a single-tenant private cloud, the same questions resolve much more crisply:

• The hardware is yours. There’s no other tenant.
• Your provider’s staff access is logged and attributed to named individuals — you can read their access logs, not infer from a shared-service report.
• The subservice chain is shorter, which usually means fewer carve-outs and a tighter inheritance map.

The auditor’s chain of evidence gets cleaner. So does the reviewer’s understanding of what’s actually running where. For a deeper look at the trade-offs, see Private Cloud vs. Public Cloud for Regulated Industries.

Red flags in provider claims

Five things that should make you slow down:

1. No named audit firm. A real SOC 2 report has the CPA firm’s name on the cover. If a provider can’t or won’t tell you who their auditor is, their report isn’t one you’d want to rely on.
2. “We’ve been SOC 2 compliant since 2015” without a current report. Compliance isn’t a status you hold; it’s a period your most recent report covers. Currency matters.
3. A Type I masquerading as Type II. Check the report type explicitly. Some marketing teams blur this.
4. No CUEC list or a very short one. Every real SOC 2 report has complementary controls. A short or missing list usually means the provider hasn’t thought through inheritance.
5. Refusal to sign a customer data processing addendum. Not a SOC 2 requirement per se, but a good litmus test. Providers who are serious about compliance don’t fight DPAs.

What to do next

If you’re choosing a provider as part of SOC 2 prep:

1. Get the report and the bridge letter before you sign anything. Read both.
2. Map every CUEC to a control you’ll operate. This is the work your auditor will want to see.
3. Ask about subservice chain and confirm each upstream party either has its own SOC 2 or is covered by yours.
4. Run one audit-style evidence request during evaluation. If the provider stumbles, you’ve learned something useful before the real deadline.

SOC 2 is a lot of work either way. The right hosting provider can cut it down by half. The wrong one can add an auditor finding you didn’t see coming.

Phoenix Network Solutions runs SOC 2 Type II controls on dedicated, single-tenant infrastructure for regulated industries. If you want to see our report, CUEC list, and subservice chain — start a conversation and we’ll send everything over under NDA.