Does Your Cloud Provider's SOC 2 Cover Your SaaS?

Your cloud provider’s SOC 2 report does not automatically cover your SaaS. It describes the provider’s scoped system and controls, while your company still operates its application and its side of the cloud service. The report can help you assess a provider and explain part of your service to a buyer. If the buyer asks for a SOC 2 report on your company, confirm the service, report type, and deadline it needs before offering the provider’s report as an answer.

Why the provider’s report has a different boundary

The AICPA’s SOC 2 Description Criteria address management’s description of a service organization’s system. That description has a defined boundary, not a blanket claim about every company that uses the service. A cloud provider’s report addresses the system named in its report. Your hosted product adds code, accounts, settings, people, procedures, data flows, and customer promises that may sit outside that boundary.

AWS describes security and compliance as shared responsibilities. AWS manages the infrastructure behind its cloud services, while a customer manages responsibilities that depend on the services it selects. For example, the customer manages application software and certain configurations. The split changes with the service, so do not apply one generic diagram to every part of your stack.

For your own SOC 2 examination, the question is which service your company provides and which controls support it. The SOC 2 scope guide helps you draw that boundary before writing a control list. A qualified CPA firm agrees on the engagement scope and evaluates the evidence. A provider report is one input to that work, not a report issued on your company.

Map the controls before you answer a buyer

Start with a real customer path through your product: sign-in, data storage, code deployment, support access, and incident handling. For each step, name the party that takes the action and the system that records it. This small example shows why the cloud report alone cannot answer every question:

Question from a buyer	Provider-side evidence to check	Your team’s evidence to check
Who protects the underlying facilities?	Provider report scope and relevant controls	Your review of the provider and the service you use
Who can access the production application?	Provider’s controls for its own personnel and infrastructure	Your identity settings, grants, reviews, and removals
How are application changes released?	Provider’s controls for the cloud service it operates	Your code review, build, deployment, and rollback records
How is customer data backed up?	Provider service features and any applicable report coverage	Your backup settings, ownership, monitoring, and restore tests

The exact split depends on your architecture and the report’s stated scope. Do not claim that a control is covered because the provider offers a feature. Check that the feature is enabled and operated in your environment, and keep the source evidence for your part of the work.

Read the provider report for the service you use

First obtain the current report through the provider’s approved channel. For AWS, AWS Artifact lets account users access AWS reports, including SOC reports. AWS says downloaded reports can carry a unique watermark and may have sharing terms. Check those terms before sending the file or storing it in a repository.

Read the report with your actual use in mind:

1. Match the named provider and covered services to the services in your architecture. A report for a different service does not answer the same question.
2. Record the report type, criteria, covered period, opinion, and any exceptions. Note any gap between its period and the date your buyer asks about.
3. Identify providers the report relies on and any controls it says the customer must operate. Decide which of those duties apply to your setup.
4. Link each applicable duty to a named owner, your control, and the source evidence that shows the work happened. Record any gap and follow-up.

This is part of a risk-based vendor review, not a substitute for one. The provider’s report may support a decision to use the service, but management still decides what risk to accept and what its own team must operate. The guide to complementary user entity controls explains how to turn a provider report’s customer duties into checks against your own controls without copying them into the wrong part of your report.

What should you send when a buyer asks for SOC 2?

Ask what the buyer wants to assess. If it asks whether your cloud provider has an independent report, you may be able to point it to the provider’s approved report channel or share the report under its terms. Say which provider service the report covers. If it asks for a report on your SaaS, state plainly whether your company has one, which service and period it covers if it does, and when you expect to have one if you do not. Do not rename the provider’s report as your own.

If your own report is still planned, offer only evidence you can support now: the provider review, your service boundary, implemented controls, dated source records, and a realistic candidate plan. A sales promise or a folder of provider reports does not replace control operation or a CPA examination. The startup SOC 2 decision guide helps you decide whether pursuing your own report answers the buyer’s request.

If the cloud provider is a subservice organization in your planned report, the carve-out versus inclusive guide explains how to record its treatment with the CPA firm.

You can maintain the provider inventory, review decision, control ownership, and evidence references in FileGRC’s Git-native GRC workspace. JSON holds structured records, Markdown holds long-form work, and Git supplies the change history. Starter records are proposals, not compliance claims. Your cloud, identity, source-control, and backup systems still operate the controls and produce source evidence. The independent CPA firm performs the examination and decides whether evidence is sufficient.