Our Cloud Provider Has SOC 2 —
Why Do We Need Our Own?

No, and the provider does not claim it is. AWS publishes SOC 1, SOC 2 and SOC 3 reports on its own system while simultaneously publishing a shared-responsibility model stating that AWS is responsible for security of the cloud and the customer for security in the cloud. Your customers are exposed to your identity decisions, your configuration, your code and your incident response — none of which appear in the provider’s report.

Microsoft publishes the clearest version as a matrix: customer data, configurations and settings, and identities and users stay with the customer in every deployment model — on-premises, IaaS, PaaS and SaaS alike — while physical hosts, physical network and datacenter move to the provider as you move up the stack. Applications, network controls and the operating system are shared or provider-owned depending on the model. In practice, access management, encryption configuration, logging you enable, code you write and data you classify remain yours however managed the platform is.

Almost always. A subservice organization is one whose controls are necessary, in combination with yours, to provide reasonable assurance that your service commitments and system requirements are achieved — and a hosting provider running production meets that test plainly. It is then handled under criterion DC7 by the carve-out or inclusive method; in practice always carve-out, because the inclusive method requires the subservice organization’s own written assertion and evidence access, which no hyperscaler provides.

No. Carve-out changes what your description includes and what your auditor tests; it removes no applicable Trust Services criterion. DC7 in fact requires the description to identify each applicable criterion intended to be met by controls at the subservice organization, so the delegation is named rather than silent — and for anything inside your own tenancy that disclosure is not available to you. Your description must also state the types of controls you assumed the provider performs, and disclose the controls you operate to monitor it. DC section 200’s implementation guidance for DC7 names, among qualifying monitoring controls, inspecting the provider’s Type 2 report, reviewing output reports, evaluating performance against service-level agreements and periodic discussions. Those are your controls, and they are tested.

CUECs are controls a service organization assumed, when designing its system, that its customers would implement, and which are necessary in combination with its own controls to achieve its service commitments and system requirements. Criterion DC6 requires their disclosure. In a cloud provider’s report they sit inside the system description — conventionally Section 3 — usually headed “complementary user entity controls” or “user entity responsibilities”. Extract every item, assign an owner, and map each to one of your own controls.

That is normal, and solved with arithmetic rather than argument. Provider periods follow their calendar: AWS publishes a Spring report covering 1 April to 31 March and a Fall report covering 1 October to 30 September, while Microsoft runs a rolling twelve-month window with period ends of 31 March and 30 September. Hold whichever reports collectively span your observation period — often two — and cover any remaining tail with whatever the provider issues for that purpose. Microsoft publishes bridge letters covering the gap between report periods on the Service Trust Portal; AWS does not issue bridge letters at all, publishing a SOC Continued Operations Letter in AWS Artifact instead. Document the result as a schedule rather than a sentence.

No. Exceptions in a carved-out subservice organization’s report are deviations in that organization’s controls, which sit outside your description boundary and outside your opinion. What is inside your boundary is the review control you operate: your auditor wants evidence that you read the exceptions, assessed whether they touch the services you consume, and reached a documented conclusion. “Reviewed, not applicable to the services we use” is acceptable when it is written down, with a reviewer and a date.

It shrinks one control, not the scope. Guest-operating-system patching genuinely moves to the provider on managed runtimes, but vulnerability management does not go with it — your container images, dependencies and third-party libraries still fall under the criterion covering susceptibilities to newly discovered vulnerabilities, and your scan cadence and remediation timelines are still tested. Identity, key policy, network configuration, logging, change management and data handling are unaffected by the service model.

The AICPA sets no sample sizes for a SOC 2 — the extent of testing is the service auditor’s professional judgment, based on the nature and frequency of the control, how automated it is, and the expected deviation rate. Firm practice converges on a frequency ladder: one item for an annual control, two for a quarterly one, two to five monthly, five to fifteen weekly, fifteen to twenty-five daily, and twenty-five to forty for a control that recurs many times a day. Event-driven populations such as incidents and emergency changes are sized to the population, often tested in full when there are fewer than about ten. The auditor selects the items; you produce the complete population. A deviation triggers extended testing, so treat those numbers as a floor rather than a budget.

A mature cloud platform genuinely reduces effort, because the infrastructure and physical-security layer is evidenced by the provider’s report rather than built by you. It does not change the shape of the engagement, because the controls examined are yours. TCSA scopes readiness, implementation and evidence work at a fixed fee from $4,000 for early-stage startups, quoted after scoping. The CPA firm’s attestation fee is separate and billed by that firm — TCSA coordinates the examination and never issues the opinion.