By Jason Williams · Updated April 2026

The 10% misread that kills first-time SOC 2 audits

The founder wrote back at 11 p.m. on a Tuesday: "Jason, the auditor is asking for 64 things. I thought we just needed to be on AWS." He'd closed an enterprise deal the month before on the back of a single line in the MSA — "hosting provider maintains SOC 2 Type II" — and had pointed procurement to the AWS Trust Center. Now he had a 64-row control matrix from his auditor and a host attestation that cleanly covered about 10 of those rows. The other 54 lived inside IAM policies, logging pipelines, a change-management process, and backup-restore drills — none of which existed when the contract was signed. I've seen three versions of this exact email in the last year. The host is never the problem. The misread of what the host's SOC 2 actually transfers — that's the problem.

This is the misread. SOC 2 is not a sticker you buy by choosing the right cloud. It's an AICPA attestation against the five Trust Services Criteria, and the portion your host can attest to on your behalf is structural: data-center physical access, hypervisor patching, storage-layer encryption primitives. The 85% your auditor will actually ask about — who has admin on prod, how keys rotate, which alerts page someone, whether you tested restores this quarter — none of that is covered by your host. Ever. Even if you're on AWS.

"SOC2: the screenshots will continue until security improves… auditors ask for evidence in the form of screenshots of enabled features — 'that checkbox over there, you should screenshot that.'"
— Thomas Ptacek, Fly.io co-founder, fly.io blog, July 2022

Ptacek's point lands hard the first time you live through it. SOC 2 is a paperwork regime — a structured ritual where you and your host split the evidence. The ritual has real value (it forces you to document), but you do not get to inherit it by proxy. Hosts cover the part of the building that's theirs. You cover everything you built on top.

The rest of this piece is about doing that split honestly. I've read enough of these reports — 150-page PDFs from four hyperscalers and three managed-WP shops — to know where to look, which 15 pages actually matter, and where founders consistently miscount.

What a host's SOC 2 Type II report actually gives you

A SOC 2 Type II report, regardless of who wrote it, has the same skeleton. Ordered roughly how they appear in the PDF:

1. Independent auditor's opinion — 2 to 4 pages. Unqualified ("clean") or qualified (auditor flagged something). If it's qualified, read why before anything else.
2. Management's assertion — the host's own claim about what their system does.
3. System description — 20 to 60 pages of how the host's infrastructure is architected, deployed, monitored, responded to.
4. Applicable Trust Services Criteria — which of the five categories are in scope. Security is always in. Availability, Confidentiality, Processing Integrity, and Privacy are optional.
5. Tests of controls and results — the big section, often 80 to 120 pages. Each control, the test, the sample size, the result.
6. Complementary User Entity Controls (CUECs) — the section founders never read. Usually 15 to 25 pages. This is where your work lives.
7. Exception list — deviations the auditor caught. Treat these as free intelligence about what the host almost got dinged for.

The CUEC section is the contract. When the host's auditor writes "the service organization's controls are designed to operate effectively only if complemented by the user entity's controls," they are handing you a list of things you must do for their attestation to flow through to your audit. If you skip those controls, the host's 38-control attestation gives you nothing usable. Your auditor will nod politely and ask for the same evidence again.

Here's the rough inheritance math, from the reports I've actually opened:

Table 1 — Trust Services Criteria × Inheritable from a typical cloud host

Blended across a typical SaaS control matrix of 60 to 80 controls, that works out to about 10-15% inherited. Call it one in eight. This number is the thing nobody writes on their marketing page because it doesn't sell hosting.

Infra-heavy vs App-heavy: where your scope actually lives

The inheritance share isn't fixed — it moves with where your scope sits. Two rough buckets:

App-heavy scope (99% of readers). You're a SaaS. Your product is the application. Your controls live in code: who can deploy, who can read production data, how session tokens are minted, what gets logged and for how long, how you detect an exfil. Your host is the floor, not the building. A managed platform like Kinsta ($35/mo Starter) or WP Engine Essential Startup ($20-25/mo on annual) or a Cloudways DO 1GB stack ($14/mo) gives you the 10-15% shared-responsibility base. The other 85% is your engineering calendar for the next 4 to 6 months.

Infra-heavy scope. You're a hosting reseller, MSP, managed-services shop, or a data-processing company running your own control plane on bare metal. Your scope now includes the physical and network layers most SaaS companies inherit. You probably need IaaS under you — DigitalOcean droplets ($6/mo for 1GB Basic), Vultr Cloud Compute ($6/mo 1GB), or the hyperscalers — and you'll be writing far more custom controls. Your inheritance share drops, because you are now a service organization that someone else will inherit from.

If you're reading this and you don't know which bucket you're in, you are almost certainly App-heavy. Hosting resellers know they are hosting resellers.

"~$20k for an auditor to walk through the process is likely the cheaper part — you'll probably lose more money in internal staff hours dealing with evidence collection than the auditor fee itself."
— HN commenter, Ask HN 38021061

That comment is worth internalizing before you pick a host. The dollar cost of a first SOC 2 Type II audit — CPA fees, automation platform, readiness assessment — lands somewhere between $25,000 and $50,000 total, per Workstreet's published breakdown, with automation platforms (Vanta, Drata, Secureframe) adding another $10,000-$20,000 per year and cheaper options like Sprinto starting around $4,000-$5,000 annually. Pure CPA fees alone run $10,000-$50,000; a readiness assessment adds $10,000-$15,000. But the real bill is the founder or senior engineer's time: 50-100% of a person for roughly four to six months. That's the thing a "SOC 2 compliant host" will not shave off. Picking the wrong managed host might cost you $50 a month. Misreading scope costs you a quarter.

Who actually publishes SOC 2 Type II reports (the 2026 hosting map)

Below is the map, organized by host class. The only columns that matter for scope decisions are attestation status and how you get the report. Everything else is signaling.

Table 2 — Hosting providers × SOC 2 Type II attestation (2026)

Two things to call out on this table. First, the expected wait to actually receive a report varies enormously. AWS Artifact is instant — you log in, accept the NDA, download. Kinsta and WP Engine typically want a signed MNDA and route it through legal; I've seen it land in 3 days and I've seen it stretch to nearly 3 weeks depending on who's on vacation. SOC 3, which Liquid Web publishes openly, is a sanitized public version — readable but not usable as primary audit evidence.

Second, the shared-hosting row is where founders get the nastiest surprise. Bluehost, Hostinger, and GoDaddy shared plans don't publish a SOC 2 report — not Type I, not Type II. This isn't a gap in my research; it's a product posture. Shared hosting is a commodity mass-market product and the unit economics don't support an annual six-figure audit per shared cluster. If you're on a $3/month shared plan and your enterprise customer is asking for a SOC 2 report, the host cannot give you what you need, full stop. No workaround on that, because there's no report in the first place.

The CUEC section you never read — what auditors actually ask you about

Here's where the article turns on you. Up to this point I've been handing you a shopping list. Now I have to tell you the shopping list is not the point. The point is what's inside the CUEC section of whichever report you end up with.

"If all you do is request SOC 2 reports from vendors and file them away, you're not really managing vendor risk — you're just creating a false sense of security."
— Medium / vendor risk management commentary

That's the most honest sentence I've read on this topic. Most founders stop at "we have it on file." The CUEC section is the part that forces you to build matching controls on your side. Seven controls show up in nearly every cloud-host SOC 2 report I've read:

1. IAM role and credential rotation. Host: the IAM service runs and is available. You: enforce MFA, rotate keys on a schedule, revoke on offboarding, document the policy, sample evidence.
2. Data encryption at the application layer. Host: storage is encrypted at rest with their KMS primitives. You: decide what's sensitive, pick an encryption strategy above storage, manage customer-specific keys if you commit to them.
3. Logging and monitoring configuration. Host: platform logs exist and are retained per their SLA. You: turn them on for your resources, ship them somewhere queryable, configure alerts, review anomalies on a documented cadence.
4. Incident response runbook. Host: their SIRT will notify per their policy. You: your own IR plan, on-call rotation, evidence of at least one tested incident per year.
5. User provisioning and deprovisioning. Host: their console gives you RBAC primitives. You: a ticketed, auditable process for granting and revoking access with periodic review.
6. Backup verification and restore testing. Host: snapshots run. You: actually restore one, quarterly, and document that it worked.
7. Change management. Host: their platform changes go through their process. You: your own deploy pipeline gates — PR review, CI, prod approval — with sampling for audit.

Print that list, sit with your engineering lead, and go through it honestly. For each line, ask: "If an auditor asked me today to show three months of evidence for this, could I?" That self-assessment is your real readiness score. The host's SOC 2 report did not move the needle on any of it.

On exceptions — every SOC 2 Type II report I've opened has had at least one, including reports from the cleanest-reputation vendors. That does not make the report "bad." It means the auditor did their job. But you need to read the exceptions on the criteria your auditor cares about, because if the host was qualified on, say, a logging-retention control and your own logging inherits from theirs, you have a problem you need to describe in your own narrative. You don't hide it. You note it, and you explain what compensating control you run.

The vendor assessment your auditor wants back

SOC 2 auditors will ask you for a vendor assessment on every third party that touches regulated data or the control environment. Your host is almost always on that list. The assessment isn't the 200-question SIG Lite your enterprise buyers throw at you — it's a focused 7-item packet. If you get this together cleanly, the auditor moves on fast.

Each item is a request you make of the host, not an internal document. Subject-line template that works: "[Company] — Annual vendor review request — SOC 2 Type II report + supporting artifacts."

1. Current SOC 2 Type II report (Type I only if you're pre-Type-II and buyer accepts). Note the audit period — you want one ending no more than 12 months ago.
2. Sub-service organization disclosure. Who does the host rely on (e.g., Kinsta runs on GCP, Cloudways runs on hyperscalers)? Your auditor will want to see those inherited dependencies.
3. DPA, and a BAA if you handle PHI (BAA is a HIPAA instrument, not a SOC 2 one, but auditors often want to see vendor contracts that cover the data you say is confidential).
4. Breach notification SLA. Some contracts say 72 hours, some say "without undue delay." You need a number, in writing, because your customer contracts probably promised a number too.
5. Data location / residency confirmation. Which DCs are in scope, which region hosts your data today.
6. Encryption in transit and at rest confirmation. The attestation covers it in general; your vendor file should have it stated explicitly for the services you use.
7. Sub-processor list with change-notification policy. How you learn when they add one. This matters to your own customers' privacy notices.

Expected response time on the whole packet is 5 to 15 business days at managed hosts, 2 to 4 weeks if legal loops in, immediate for AWS Artifact (you pull it yourself). If your host takes longer than 30 days on request #1 and can't give you a reason, treat that as a signal and check the Trust Center — if it's not there either, that tells you something.

A small confession on this packet. The first time I helped a client pull it together I underestimated how much of it was the host's job. I sent back a half-done draft and watched the auditor circle three missing items with a kind of weary patience I've come to recognize. It stung, because I'd written 7 items down in a neat ordered list and assumed "list = plan." It isn't. Each item has a request, a received artifact, a filing location, and a renewal date. Miss any of those and the packet is decorative, not audit-usable. That was the week I started treating vendor assessment as an operations function with its own calendar, not a document.

Verdict: pick by scope, not by marketing

If you read one section of this article, read this one. The hosting recommendation depends entirely on where your scope lives, not which brand has the shiniest compliance page. Whatever you pick, you're buying the same 10-15% inherited floor — the 85% that actually fails audits still belongs to you. The question below isn't "which host makes me compliant"; it's "which floor fits the building I'm putting on top of it."

If you're App-heavy SaaS and want the most inherited floor per dollar

Pick a managed platform with a real Type II and a Trust Center that will actually send you the report. Kinsta at $35/mo Starter or $115/mo Business 1 gives you a 38-control Type II audited by BARR Advisory plus ISO 27001 — easily the cleanest documentation stack in managed WordPress. WP Engine at $20-25/mo on annual Essential Startup is the second choice; the report is solid, the NDA dance slower. Cloudways at $14/mo on a DO 1GB starter is the budget play — you get Type II, but the Trust Center process is less polished. All three save you the time of stitching together your own stack on raw IaaS. This recommendation does not apply if your application handles cardholder data in scope for PCI DSS or PHI under HIPAA with a signed BAA requirement — those frameworks want contract language and segmentation that managed WordPress platforms don't offer at these tiers. Go IaaS with an enterprise contract instead.

If you're Infra-heavy or building your own control plane

DigitalOcean ($6/mo 1GB Basic Droplet) or Vultr ($6/mo 1GB Cloud Compute) is the right floor. Both have public Type II attestations, both will give you raw Linux and let you own every control. AWS is the other option if you need enterprise-grade sub-service documentation — Artifact makes the report painless — but you'll pay for it in complexity and billing.

If your customer is enterprise or in a regulated industry

Liquid Web Managed Cloud VPS at $59/mo 2GB, or Nexcess Spark at $21/mo managed WordPress, is the move if you want SOC 1 + SOC 2 + HIPAA-capable all in one vendor. Liquid Web publishes SOC 3 openly, which some procurement teams will accept as a pre-check before signing an NDA for the full SOC 2. If your enterprise buyer is serious and your scope is large, skip managed and go AWS with enterprise support — the scoping hooks, contracts, and sub-processor disclosure are all built out.

Do not use for SOC 2 scope

Bluehost, Hostinger, GoDaddy shared, and any commodity shared-hosting plan. No attestation, no CUEC document to inherit from. Marketing-page "secure hosting" is not the same thing. Rocket.net at product level isn't publicly attested either; they lean on Cloudflare and GCP underneath, which means your auditor has to scope those instead. Workable if you know exactly what you're doing, painful if you're doing a first audit.

When this whole strategy doesn't apply

• Re-certification scope — you're already SOC 2 and switching hosts is a vendor transition, not a scope decision. Different playbook.
• FedRAMP High government contractors — SOC 2 is a minimum bar, not a selection criterion. You need a FedRAMP-authorized host and a different article.
• Pre-revenue SaaS with no real customer data yet — you may not need SOC 2 at all. Doing a $25,000-$50,000 audit to close one skeptical customer is often the wrong trade. Ask them if Type I plus a security questionnaire gets them to yes. Half the time, it does.

One personal note to close on, circling back to the opening. When a founder shows me their Trust page and the SOC 2 logo from their host is prominently featured and I click through and there's no CUEC mapping, no vendor assessment file, no reference to their own controls — I know exactly how their first audit is going to go. The fix isn't a better host. It's reading the 15 pages of the host's report that you skipped, listing the seven controls in the section above, and honestly answering the question: can I produce three months of evidence for each one?

If the answer is no today, that's fine. That's what the next four months are for. Nobody inherits that part.

FAQ

My host has SOC 2 Type II. Does that mean my SaaS is SOC 2 compliant?

No. As Secureframe puts it in their AWS SOC 2 commentary, "Many companies mistakenly think that choosing a SOC 2-compliant cloud provider makes them SOC 2-compliant. It doesn't." Your host's report covers the infrastructure layer — roughly 10-15% of a typical SaaS control matrix. Your application, access, logging, change management, and incident response are yours to attest to. The host's report is an input to your audit, not a substitute for it.

Can I do SOC 2 Type I first and upgrade to Type II later, or is that wasted money?

Depends entirely on who you're selling to. Type I is a point-in-time design assessment — roughly $10,000-$15,000 in readiness work, plus CPA fees on top — and a lot of SMB and startup buyers accept it. Enterprise procurement, regulated industries, and most public-company buyers want Type II only. If your pipeline is mid-market SaaS and below, do Type I to close deals this quarter and schedule Type II in 6 to 12 months once you have the observation period. If you're selling to a Fortune 1000, skip Type I; they won't accept it anyway, and you'll pay twice.

Is shared hosting ever SOC 2 acceptable, even for a simple SaaS?

No. Bluehost, Hostinger, and GoDaddy shared plans don't publish any SOC attestation — Type I or Type II. Without an attestation, you can't inherit anything from them, which means every control they would have covered is now your responsibility to build from scratch, on a platform where you don't have the access or control granularity to do it. Even for a three-user SaaS with minimal data, it's cheaper in auditor hours to move.

Do I actually need to read my host's 150-page SOC 2 report?

Read 15 pages of it. Specifically: the auditor's opinion (2 to 4 pages), the exception list (usually 1 to 3 pages), and the CUEC section (15 to 25 pages). That's where 90% of the audit-usable content lives. The 100 pages of control test results are for your auditor to pattern-match; you'll only dig in if your auditor asks a specific question about a specific control.

AWS, GCP, and Azure all have SOC 2. Which one's report is easiest for my auditor to work with?

AWS by default, with two specific exceptions. AWS Artifact gives you direct access after a click-through NDA — log in, download, send to your auditor. The CUEC section is explicit, sub-service organizations are clearly named, and most US-based SOC 2 auditors have read AWS's report template enough times to skim it fast. That saves you auditor hours, and auditor hours are billable.

Choose GCP instead when your product is already Google Workspace / BigQuery / Firebase-heavy — the Compliance Reports Manager lets you pull a combined bundle (SOC 2 + ISO + CSA STAR) matched to the exact services you consume, which is cleaner than stapling three separate AWS reports together. Choose Azure when your buyer is government-adjacent or enterprise and wants FedRAMP / HIPAA / ISO 27001 evidence alongside SOC 2 — Service Trust Portal bundles them in one place, which shortcuts procurement questions. Decision rule: "which one does my auditor already know how to read" beats "which one looks best on a marketing page." If you don't have an auditor yet, default to AWS.

My host's SOC 2 report is under NDA and my legal team is slow. Can I use their public SOC 3 instead?

SOC 3 is a sanitized public version of a SOC 2 report. It proves attestation exists but strips the control-test detail and CUEC specifics — which are exactly the parts your auditor needs. It's useful as a pre-check to show procurement, but not as primary audit evidence. Practical workaround: request the report via the host's self-serve Trust Portal first (AWS Artifact, Google Compliance Reports Manager, Azure STP, or DigitalOcean Trust Portal) — these have a click-through NDA that doesn't need your legal team. For managed WP hosts like Kinsta or WP Engine where the NDA does route through legal, use the SOC 3 (where available, e.g. Liquid Web) to keep procurement moving while the full SOC 2 makes its way through.